Thread (44 messages) flat view 44 messages, 6 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:45:25

Paul Mackerras schrieb:
Alexander Gavrilov writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help