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

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

----- Ursprungligt meddelande -----
> 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?

The problem is that I'm converting a repo from clearcase to git and
there are lots of symbolic links. Symbolic links in clearcase on 
Windows is treated as file copy in snapshot views which means that
you get a copy of the linked file when you update the view. If the
link target changes you can update your view to refersh your copies.

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

You're right.

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

I want the copy on checkout. The intent is to change things and
then commit.

Perhaps I can convince people to let a script copy stuff instead.

-- robin