Re: Interactive rebase encoding

From: Constantine Plotnikov <constantine.plotnikov@gmail.com>
Date: Dec 15, 2008, 16:21 UTC
Message-ID: <85647ef50812150821g4a032af0u31425fd7f4c0fd9@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0812151652400.30769@pacific.mpi-cbg.de>

On Mon, Dec 15, 2008 at 6:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 13 quoted lines

> Hi,
>
> On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
>
>> The interactive rebase command builds a text file and passes it to
>> editor specified as environment variable or as configuration parameter.
>> However the man page for rebase operation says nothing about which
>> encoding will be used for that file. Apparently i18n.logoutputencoding
>> is used.
>
> As rebase -i does nothing else than piping the output of git log into a
> file (at least this is the first step), I thought it would be obvious that
> it uses the output encoding preferred by the user.

Yes. That was my first hypothesis, but I had to check it through small experiment and source code examination. And if consider the bug described in the thread http://kerneltrap.org/mailarchive/git/2008/11/11/4063184, the hypothesis might have been incorrect.

>
> Indeed, I cannot think of any scenario where it might make sense to have a
> different encoding in git rebase -i than in git log.
>

For IDE, it might make sense to force UTF-8 encoding instead of using currently configured logoutputencoding. Currently the extra call to git config is needed to check expected encoding of the file before data could be shown to the user. Also user specified encoding might fail to display some characters in commit messages that was encoded using other encodings, forcing UTF-8 would have also fixed this problem as well.

BTW for IDEs an option that causes non-abbreviated commit hashes would have been useful as well.

Constantine