Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > It is obvious that we do not have to create directories when the file we > want to check out already existed. > > Besides, it fixes the obscure use case, where you want to track a > file which is _outside_ of your working tree, by creating a symbolic > link to the directory it lives in, and adding the file with > something like "git add symlink/file". Without this patch, "git > checkout symlink/file" would actually _replace_ "symlink" by a > directory of the same name. Uh, when git is tracking symlinks (and it does by default), this is quite the correct thing to do. Of course, it should rather barf with a merge conflict. But it has no business following links and doing potential damage either outside or inside of the work tree, by confusing the target of a link with the link itself. For example, I can easily relocate a complete git work tree with "mv" in the directory hierarchy. Should an update/commit/whatever then start wreaking havoc in places that incidentally don't point to the same location anymore? My vote here is emphatically "no". Just maintain the links, not whatever they point to. I can think of only a single reasonable exception: if the symlink itself is _not_ registered (because is has been explicitly entered into a .gitignore file or never added for other reasons), but its target _has_ been added explicitly _dereferencing_ the symlink. This difference can only occur with directory symlinks since file symlinks can't be distinguished in this manner from the name of the link itself. It would be good if somebody brought this to Johannes' attention, even if just replying with a quotation: he chose to killfile me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
