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

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Sep 19, 2010, 08:58 UTC
Message-ID: <vpq8w2yt8hc.fsf@bauges.imag.fr>
In-Reply-To: <7vpqwa254i.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> 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).

Yes, and my question was to make sure we don't run the textconv filter on these strings.

I've just checked, and from my little tests, git diff doesn't try to textconv the pathnames, it runs the textual diff without textconv, which is the expected behavior.

> 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.

No, we don't do that. And yes, it's good not to do that: AFAIK, Git never looks at the file symlinks points to (which allows one to store broken symlinks or symlinks pointing outside the repository).

Show 7 quoted lines

> 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.

If a symlink points to "foo.pdf", then you really want to call the string "foo.pdf" a pathname, not a "content", although it happens to be stored in a blob content.

If you have a program that can textconv PDF files, then you really want to say

*.pdf textconv=the-driver-for-that-program

in your .gitattributes file, and let Git call the program on _files_, not pathnames, and hence not symlink target (i.e. result of readlink).

If you think Git should call the textconv filter on pathnames, and let the driver decide whether to call it depending on whether it's a file content or a symlink target, then you should 1) give a use-case where it's usefull to textconv symlink targets (I really don't see any, and even on highly artificial examples, I can't imagine one where the same driver should textconv file content and pathnames), and 2) tell us the syntax to use in .gitattributes or in the driver to call it only on file content (I don't know any, and the .gitattribute manpage doesn't containt either "link" or "mode", so I don't think there is actually any).

So, I'm pretty sure either I misunderstood you or you misunderstood something ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/