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