> From: Norike Abe <nor...@gmail.com>
> 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
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
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
For more options, visit https://groups.google.com/d/optout.