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

[Michael J Gruber <git@drmicha.warpmail.net>]

Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
> 
> 
> ----- 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
> 

Well, what is the problem at hand?

Your commit message begins in present tense as if it described the
current state of git, when in fact it describes what the patch is about
to achieve. This is confusing enough already,

I don't see any mention of the purpose, other than "content may be
used", which would be served perfectly by a copy-on-link feature on the
export side, as mentioned by Junio. Is git-archive|tar an option?

Michael