Re: When exactly should REBASE_HEAD exist?

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Mar 19, 2023, 14:50 UTC
Message-ID: <0eb3ed02-139a-b114-939a-d2ad286af743@dunelm.org.uk>
In-Reply-To: <f7577c57-f70d-cca3-3f25-18525d40d79b@dunelm.org.uk>

Hi Stefan

On 16/03/2023 17:46, Phillip Wood wrote:

Show 17 quoted lines

> Hi Stefan
> 
> On 10/03/2023 17:42, Stefan Haller wrote:
>> I tried the algorithm now and seems to do exactly what I want, so thanks
>> for the help with this, I'm happy now.
> 
> I'm glad you've got something working
> 
>> There's a slight correction though: if a command is rescheduled, then
>> git appears to re-append the last successful command to the end of the
>> "done" file (it's in there twice now). So I have to check the > 
>> second-to-last command of "done" against the first command of
>> "git-rebase-todo" to find out if a command was rescheduled.
> 
> Oh, sorry I'd misremembered how it works. I think it is actually a bug 
> that we write the last successful command to "done" again when 
> rescheduling but it sounds like you have a reliable work-around.

Hmm, I think it is a bit complicated to do this reliably as if "pick B" has conflicts and git-rebase-todo contains

	exec make test

and done contains

	pick A
	exec make test
	pick B

it looks like "exec make test" has been rescheduled when in fact "pick B" failed with conflicts. If you look at the last three lines of "done" you can distinguish the two cases but it is a bit of a faff. I've submitted a bugfix at https://lore.kernel.org/git/pull.1492.git.1679237337683.gitgitgadget@gmail.com

Best Wishes

Phillip

Show 5 quoted lines

> Best Wishes
> 
> Phillip
> 
>> -Stefan