Re: [PATCH] checkout_entry: only try to create directories when no file existed there

[David Kastrup <dak@gnu.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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