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

[Junio C Hamano <gitster@pobox.com>]

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

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

That largely depends on what purpose each symlink is used for in the
project.

Suppose you have a symlink A and another symlink X in the project,
where A points at another path B inside the working tree, and X
points at a path outside, say, /etc/motd.  Upon checkout, you make
regular files A and X that store the contents of the files they
point at, and then you edit A and X.

Now, what should happen on the next "git add A X"?

 * Perhaps it (or any step before "git add", or something even
   outside git) should notice that you modified A that is supposed
   to represent a copy of B but their contents have drifted.  It
   should raise a red flag, or take a remedial action, no?

 * Perhaps it should copy the updated contents in A to B and run
   "git add" on that one instead, without changing anything else?

 * Imagine a project with many template files B, C, ..., where A
   points at "the default template".  You may be designating a
   different template file as the new default.  On a symlink-capable
   system you would just do "rm -f A && ln -s C A", but because you
   chose to make a copy of B and store it as a regular file in A, a
   natural way to update it may be to do "cp C A".

   Would you find another file C in the working tree that may be
   different from B that has the same contents as A, and update the
   symbolic link A to point at C instead?  Do so only with the
   contents of A and all the other files in the working tree?  What
   if there is another template file identical to C?

I didn't even touched the cases where you have to deal with your
updates to X.

This is looking more and more outside the scope of Git to me.