Re: [PATCH 2/2] pull --rebase: reinstate helpful message on abort

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 12, 2015, 09:16 UTC
Message-ID: <d2116a492e14f07c8969798ce21c78a2@dscho.org>
In-Reply-To: <xmqqbnc7q489.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On 2015-10-09 20:36, Junio C Hamano wrote:

Show 12 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
>> When calling `git pull --rebase`, things can go wrong. In such a case,
>> we want to tell the user about the most common ways out of this fix:
>> ...
>>  builtin/am.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> It is strange to see a patch to am that does not talk anything about
> it, though.  And looking at the codepath, the issue does not have
> much to do with "pull --rebase".  It doesn't even have much to do
> with "rebase".  This is purely about "am -3" fallback codepath.

I made it a habit of describing the big picture in commit messages, including the original motivation for the patch. Naturally, it is purely an implementation detail that the bug displayed by `git pull --rebase` is fixed by modifying `am.c`.

> Because fall-back-threeway wants to react to an error (i.e. calls
> merge_recursive_generic() and wants to use its return value), but
> merge_recursive_generic() can die, it fails to do so.  It would not
> even run rerere(), for example.

Precisely, So the symptom triggering the bug fix was seemingly unrelated to the patch, hence the need for the comprehensive commit message.

Since our tastes seem to differ a bit, maybe we can have the best of both worlds by appending the following paragraph to the commit message?

-- snipsnap -- This patch actually fixes a deeper-seated bug where the non-gentle death of the recursive merge would prevent not only the message from being shown but *any* code to run after the failed merge, including rerere.