> From: Norike Abe <[email protected]> > I'm studying the migration from our old Version Manager, Team Coherence > <http://www.teamcoherence.com/>, to Git. > > One of the features we use in that system are "file links": > Imagine a repo with this file structure: > - MyRepo1 > - Folder1 > - *FileA* > - FileB > - Folder2 > - *FileA* > - FileC > > I want FileA from both Folder1 and Folder2 to be synchronized.
What I don't see is why you'd want to have what is intended to be one file implemented by two different files. That requires some sort of machinery to ensure that the two instances of the file are always the same, and introduces the constant possiblity of error. One way to avoid this is to have one FileA be a symbolic link to the other. But I suspect you're using Windows, and it doesn't have symbolic links. Another way is to just tell every compilation and/or program that wants to access FileA the location of the one copy of FileA. Indeed, the fact that the stuff in each folder wants to access the same file suggests that the meaning or import of FileA transcends the specifics of either Folder1 or Folder2. The migration to Git might be the opportunity to rationalize your file structure. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
