Thanks for the comments, Dale!

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. 
Well, this is how the version system we are using works so I was looking 
for some way to do a similar thing with Git.

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. 

Yes, I'm afraid all the team works under Windows. :S

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

That's what I feared! :P
This means we should invest so many hours reconfiguring every project to 
use Git correctly.

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

Reply via email to