> 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
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


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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to