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

Robin Rosenberg [off-list ref] 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.