Johannes Schindelin <johannes.schinde...@gmx.de> writes:
>> > + if (strbuf_readlink(&link, ce->name, ce_namelen(ce)) == 0) {
>> > + strbuf_add(&path, state->base_dir, state->base_dir_len);
>> > + strbuf_add(&path, ce->name, ce_namelen(ce));
>> > +
>> > + write_file_buf(path.buf, link.buf, link.len);
>>
>> This does "write content into symlink stand-in file", but why?
>
> From the commit message:
>
> > Detect the null object ID for symlinks in dir-diff so that
> > difftool can prepare temporary files that matches how git
> > handles symlinks.
Yes I read what the proposed log message said, and noticed that
symbolic link is _always_ written as a regular file.
I was questioning why. I know Git falls back to such behaviour when
the filesystem does not support symbolic links. "Why do so
unconditionally, even when the filesystem does?" was the question.
> The obvious connection: when core.symlinks = false, Git already falls back
> to writing plain files with the link target as contents. This function
> does the same, for the same motivation: it is the best we can do in this
> case.
And that "obvious connection" does not answer the question.
