Re: [PATCH] RFC Optionally handle symbolic links as copies

[Robin Rosenberg <robin.rosenberg@dewire.com>]

----- Ursprungligt meddelande -----
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> 
> > If core.symlinks is set to copy then symbolic links in a git
> > repository
> > will be checked out as copies of the file it points to.
> 
> That all sounds nice on surface when the primary thing you care
> about is to fetch and check out other people's code and extract it
> to the working tree, but how well would that work on the checkin
> side?  What happens if I check out a symlink that points at a file
> (either in-tree or out-of-tree), make some changes that do not
> involve the symlink, and before I make the commit, an unrelated
> change is made to the file the symlink is pointing at?
> 
> > - git status - when do we report a diff.
> > 	- After checkout we should probably not
> > 	- if the "linked" files change?
> 
> Yeah, exactly.
> 
> > 	- if a change in the copied directory chsnges
> 
> That, too.
> 
> > 	- if a file in the copied diretory is added/removed
> > 	- update, should we update the copied structure automatically
> > 	  when the link target changes

Some of the questions have proposals in the includes test script. A 
little more dangerous than having real symlinks ofcourse, but regardless
of what one does with or without copied symlinks one can make mistakes
and I feel letting Git do the copying is way better than having real
copies in the git repository. Another crappy scm which the users are
converting from does this and it works. A difference to git is that
it (ok clearcase) makes all files read-only so there are fewer mays
of making mistakes with the copies.

> I personally do not think this is worth it.  It would be very useful
> on the export/checkout side, so it may make sense to add it to "git
> archive", though.

It makes sense, but it does not solve the problem at hand.

-- robin