Re: [BUG, PATCH 0/3] Fix {blame,cat-file} --textconv for cases with symlinks

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 18, 2010, 20:01 UTC
Message-ID: <7vpqwa254i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqhbhmx6tg.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 8 quoted lines

> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
>> Recently I've spot a bug in git blame --textconv, which was wrongly
>> calling pdftotext (my *.pdf conversion program) on a symlink.pdf,
>
> No time for a detailed review now, but textconv is also called by diff
> (that's the original implementation). Does "git diff" work properly on
> symlinks in the same case?

diff knows symlinks and regular files are different, and produces "delete old then add new" if you changed a regular file to a symlink.

That said, if you changed a symlink from pointing at A to pointing at B, it does run the textual diff between the string we get from readlink(3).

I happen to think that textconv, if specified, for such a path should be honored, so that people can keep doing whatever munging they have been doing in their existing textconv filters.

I didn't look at the thread or problem description, but are we running the textconv filter on the file that symlink points at, instead of the pathname stored in the symlink? If so I'd call that a bug.

On the other hand, if we are running the textconv filter on the pathname, then I don't think we are doing anything wrong. If you have a filter that is meant to munge a PDF file to some other format, and if you do not want to apply that filter to munge a pathname a symlink that happens to be named "foo.pdf", either the filter itself or the attributes pattern you are using to choose what paths to apply that filter might want to be written more carefully, that's all.