From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 31 Jul 2012 20:04:28 GMT
Subject: Re: [PATCH] rebase -i: handle fixup of root commit correctly
Message-ID: <50183A4C.9080706@kdbg.org>
In-Reply-To: <20120731124824.GC14028@arachsys.com>

Am 31.07.2012 14:48, schrieb Chris Webb:
> Chris Webb<chris@arachsys.com>  writes:
>
>> If we have a conflict in the middle of a chain of fixup/squashes, as far as
>> I can see, we have a HEAD with all the previous successful fixups applied,
>> conflict markers for the current failed pick, and when the conflict has been
>> resolved, git rebase --continue will commit --amend the resolution and
>> continue? Isn't that the correct behaviour here?
>
> As an explicit test, I've just tried a chain of four squashed commits, each
> of which deliberately resulted in a conflict to manually resolve. For each
> squash, I was left with conflict markers on top of what had already been
> squashed in the expected way, and when I continued after resolving these,
> the resolution was 'commit --amend'ed in the expected way, with the same
> behaviour and resulting commit at the end of the rebase -i as I get with a
> copy of git without this patch.

OK, good. One subtlety to watch out for is when commit messages are 
edited. That is, if you edit the proposed message at 'rebase --continue' 
after the first squash failed, is the new text preserved until the last 
squash? I *think* that previously that was the case.

That said, I do appreciate the new modus operandi. The state when a rebase 
is interrupted is much clearer than earlier: now HEAD contains everything 
that was successfully replayed so far, and the index anything that failed.

-- Hannes