From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Fri, 20 Apr 2018 20:38:05 GMT
Subject: Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages
Message-ID: <nycvar.QRO.7.76.6.1804202232360.4241@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <nycvar.QRO.7.76.6.1804202149260.4241@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

Hi Stefan,

On Fri, 20 Apr 2018, Johannes Schindelin wrote:

> A brief test shows, however, that it is not quite as easy as
> s/grep/test_i18ngrep/, something more seems to be broken.

It seems that this week is my Rabbit Hole Week.

Turns out that we have a really, really long-standing bug in our rebase -i
where we construct the commit messages for fixup/squash chains.

Background: when having multiple fixup!/squash! commits for the same
original commit, the intermediate commits have messages starting with the
message

	# This is a combination of <N> commits.

and then every fixup/squash command increments that <N> and adds a header

	# This is the commit message #<N>:

before writing the respective commit message.

The problem arises from the fact that we deduce <N> from parsing the first
number in ASCII encoding on the first line.

That breaks e.g. when compiling with GETTEXT_POISON, and it is probably
not true in general, either.

So I introduced a patch that handles the absence of an ASCII-encoded
number gracefully, and now the test passes with and without
GETTEXT_POISON.

Thanks for the review that let me find and fix this bug!
Dscho