Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Oct 1, 2008, 11:35 UTC
Message-ID: <48E36086.7050504@viscovery.net>
In-Reply-To: <18646.53492.20994.908025@cargo.ozlabs.ibm.com>

Paul Mackerras schrieb:

Show 13 quoted lines

> Alexander Gavrilov writes:
>> 3) It can be further set on per-file basis by specifying
>>    the 'encoding' attribute in gitattributes.
> 
> I haven't used .gitattributes before, but I would expect that the
> .gitattributes files would be stored in the repository along with
> everything else.  If that's the case, then for gitk at least there is
> the question of which version of a given .gitattributes file one
> should use when viewing the tree for a commit which isn't the
> currently checked-out commit - do you use the version from that tree,
> or the version in the working directory?  We seem to be using the
> latter at present, and caching the results.  Is there a philosophical
> reason to do that, other than speed?

I understand your concerns that an encoding may be picked from the "wrong" .gitattributes file. But in practice it doesn't matter much, and picking the attribute from a past commit's tree would even be counter-productive:

I'm about to add a .gitattributes file that specifies the encoding for some of my files *today* because I was not clever enough to anticipate the usefulness of an "encoding" attribute a year ago when those files were added to the repository. When I browse history, I *do* want that *today's* encoding is picked.

> (Also it seems that we won't
> notice if the user changes .gitattributes after we've looked at it, or
> if they create one after we've looked for one and not found it.)

This is not a show stopper, IMHO. The user will notice soon enough, and can restart gitk. Nobody sane will change the encoding attributes every hour.

That said, a menu command to flush the attribute cache would be useful every now and then.

-- Hannes