From: Junio C Hamano <gitster@pobox.com>
To: Junichi Uekawa <dancer@netfort.gr.jp>
Cc: git@vger.kernel.org
Subject: Re: Git merge conflicts and encoding of logs
Date: Tue, 23 Dec 2008 00:22:08 -0800 [thread overview]
Message-ID: <7vprjjfgi7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <87lju7h4yb.dancerj%dancer@netfort.gr.jp> (Junichi Uekawa's message of "Tue, 23 Dec 2008 13:48:44 +0900")
[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]
Junichi Uekawa <dancer@netfort.gr.jp> writes:
> Git merge conflict will insert '<<< first line of commit log message'
> '===' '>>>' markers to the text file that is causing a conflict.
>
> Unfortunately, the encoding of the text file may be different from the
> log message encoding, and that results in a file which has a mixed
> encoding (which is pretty hard to edit from any editor BTW).
>
> My use case is editing platex files (iso-2022-jp encoded) with log
> messages of utf-8.
>
> ... Thinking about it, it's probably the same encoding problem as git
> blame.
What 69cd8f6 (builtin-blame: Reencode commit messages according to git-log
rules., 2008-10-22) does to git-blame is to re-encode the data taken from
the commit log to i18n.logoutputencoding, and put that in the datastream.
If your commit object have names and messages in utf-8, and if you set
i18n.logoutputencoding to iso-2022-jp, that would reencode data taken from
the commit object in iso-2022-jp and sprinkle them in the blame
datastream.
The issue would be certainly similar, *if* anything on your <<</===/>>>
lines came from commit log message, but I couldn't trigger what you
describe. I prepared a history of this shape:
B
/
o---A
with ISO-2022-JP payload and UTF-8 commit log message. Then, I added:
[i18n]
logoutputencoding = iso-2022-jp
which lets me read "git log -p --all" quite comfortably. Everything comes
out as good old JISX0208. So far, so good.
Then while on branch B, I tried to merge A, which resulted in conflicts
that looked like this:
<<<<<<< HEAD:foo
これはサイドブランチの変更です。
やはり JIS コードで書いてます。
=======
日本語のファイルです。
JIS コードで書いてます。
>>>>>>> master:foo
The above will probably come out as UTF-8 in this mail text, but the point
is that the confict side markers do not have anything but filename and the
branch name. I am still scratching my head trying to see where in the
merge-recursive codepath you got snippet of log message.
A bundle from my test repository is attached. You can use it to reproduce
the repository like this:
$ cd /var/tmp && mkdir test && cd test && git init
$ git pull ../x.bndl master
$ git fetch ../x.bndl side:side
[-- Attachment #2: a bundle of the sample history --]
[-- Type: application/octet-stream, Size: 917 bytes --]
next prev parent reply other threads:[~2008-12-23 8:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-23 4:48 Git merge conflicts and encoding of logs Junichi Uekawa
2008-12-23 8:22 ` Junio C Hamano [this message]
2008-12-23 8:41 ` Johannes Sixt
2008-12-23 10:04 ` Junio C Hamano
2008-12-23 23:37 ` Junichi Uekawa
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=7vprjjfgi7.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=dancer@netfort.gr.jp \
--cc=git@vger.kernel.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).