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

On Mon, Sep 22, 2008 at 2:55 AM, Paul Mackerras [off-list ref] wrote:

I'm happy with providing a way to say what the default encoding of
files in the repository is, but I wonder why it is seen as a property
of the GUI.  Is it just that there is an existing "gui" section that
is convenient to use, or does git-gui already use gui.encoding (before
this patch series), or is there some other reason?

No particular reason, it can be easily renamed to i18n.encoding, or
something else. I only recall seeing the name 'gui.encoding' in a
discussion on this topic several months ago.

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

Core git does not provide any interface for reading attributes from
older commits, so they are loaded from the working copy. And caching
is necessary for performance when lookup involves calling an external
application at least once per 30 files. This may change if
git-check-attr is modified to support --stdin-paths.

quoted

There are also some bugs in handling of commit encodings in gitk,
but they are out of the scope of this series.

I'm interested to hear what they are.

When I tested it, I noticed that:

1. It works correctly only if all commits use the encoding specified
in i18n.commitencoding
2. Even when they do, sometimes commits are loaded through cat-file,
and in this case they are processed using the locale encoding.

Alexander