Robin Rosenberg <robin.rosenb...@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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html