From: "Alexander Gavrilov" <angavrilov@gmail.com>
To: "Paul Mackerras" <paulus@samba.org>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
Date: Mon, 22 Sep 2008 14:12:33 +0400 [thread overview]
Message-ID: <bb6f213e0809220312m6cb8022csa3843cfaccc5b69b@mail.gmail.com> (raw)
In-Reply-To: <18646.53492.20994.908025@cargo.ozlabs.ibm.com>
On Mon, Sep 22, 2008 at 2:55 AM, Paul Mackerras <paulus@samba.org> 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.
>> 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
next prev parent reply other threads:[~2008-09-22 10:13 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-17 21:07 [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 2/8] git-gui: Add a menu of available encodings Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 3/8] git-gui: Allow forcing display encoding for diffs using a submenu Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 4/8] git-gui: Optimize encoding name resolution using a lookup table Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 5/8] git-gui: Support the encoding menu in gui blame Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 6/8] gitk: Port new encoding logic from git-gui Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 7/8] gitk: Implement file contents encoding support Alexander Gavrilov
2008-09-17 21:07 ` [PATCH (GIT-GUI,GITK) 8/8] gitk: Support filenames in the locale encoding Alexander Gavrilov
2008-09-19 12:10 ` [PATCH (GIT-GUI,GITK) 6/8] gitk: Port new encoding logic from git-gui Johannes Sixt
2008-09-19 12:38 ` Alexander Gavrilov
2008-09-19 13:04 ` Johannes Sixt
2008-09-21 18:52 ` Alexander Gavrilov
2008-09-22 7:25 ` Johannes Sixt
2008-09-22 7:46 ` Johannes Sixt
2008-09-22 8:01 ` Alexander Gavrilov
2008-09-22 8:20 ` Johannes Sixt
2008-09-22 9:02 ` Alexander Gavrilov
2008-09-22 9:18 ` Johannes Sixt
2008-09-22 10:18 ` Alexander Gavrilov
2008-09-22 9:01 ` Dmitry Potapov
2008-09-18 15:02 ` [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding Dmitry Potapov
2008-09-18 15:14 ` Alexander Gavrilov
2008-09-18 16:29 ` Johannes Sixt
2008-09-18 16:50 ` Dmitry Potapov
2008-09-18 17:00 ` Alexander Gavrilov
2008-09-18 17:19 ` Dmitry Potapov
2008-09-17 21:45 ` [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI Paul Mackerras
2008-09-18 11:12 ` Alexander Gavrilov
2008-09-21 22:55 ` Paul Mackerras
2008-09-22 10:12 ` Alexander Gavrilov [this message]
2008-10-05 2:30 ` [PATCH 1/2] check-attr: add an internal check_attr() function Dmitry Potapov
2008-10-05 2:30 ` [PATCH 2/2] check-attr: Add --stdin-paths option Dmitry Potapov
2008-10-06 7:09 ` Johannes Sixt
2008-10-07 0:14 ` [PATCH 1/2 v2] check-attr: add an internal check_attr() function Dmitry Potapov
2008-10-07 0:16 ` [PATCH 2/2 v2] check-attr: Add --stdin-paths option Dmitry Potapov
2008-10-08 15:24 ` Shawn O. Pearce
2008-10-12 14:19 ` Dmitry Potapov
2008-10-12 15:04 ` Jakub Narebski
2008-10-12 16:35 ` Dmitry Potapov
2008-10-10 22:39 ` Paul Mackerras
2008-10-12 14:30 ` Dmitry Potapov
2008-10-01 11:35 ` [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI Johannes Sixt
2008-10-10 10:46 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb6f213e0809220312m6cb8022csa3843cfaccc5b69b@mail.gmail.com \
--to=angavrilov@gmail.com \
--cc=git@vger.kernel.org \
--cc=paulus@samba.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).