Re: When exactly should REBASE_HEAD exist?

[Stefan Haller <lists@haller-berlin.de>]

On 02.03.23 11:19, Phillip Wood wrote:
> On 28/02/2023 12:55, Stefan Haller wrote:
>> As far as I can tell, REBASE_HEAD always points to the last commit that
>> was attempted to be applied in a rebase, not matter whether that attempt
>> was successful or not. In other words, when you break in a rebase with
>> "edit" or "break", REBASE_HEAD is the same as HEAD 
> 
> As you said at the beginning REBASE_HEAD points to the commit that we're
> trying to pick, so it will only be the same as HEAD if the pick was
> successful and it was not rebased onto a new parent.

Right, I was a bit sloppy in describing the current behavior.

> I think it is
> useful to have REBASE_HEAD set when editing a commit as I find it is
> sometimes useful to look at the original commit.

OK.

>> The reason why I am asking this is: I'm using lazygit, which, during
>> interactive rebases, shows a combined view of the real commits that were
>> already applied, and the remaining commits that are yet to be applied
>> (it gets these by parsing rebase-merge/git-rebase-todo); something like
>> this, when I set the 2nd commit to "edit":
>>
>>    pick   4th commit
>>    pick   3rd commit
>>           2nd commit  <-- YOU ARE HERE
>>           1st commit
>>
>> This is great, but assuming that the 2nd commit conflicted, currently
>> the display looks like this:
>>
>>    pick   4th commit
>>    pick   3rd commit
>>           1st commit  <-- YOU ARE HERE
>>
>> I would like to extend this to also show a "fake entry" for the commit
>> that conflicted, if there is one. REBASE_HEAD is perfect for this,
>> except that I need a way to distinguish whether it was applied already
>> or not.
> 
> Can you check the index for conflicts when the rebase stops?

I could do that, but then the fake entry would go away as soon as I have
staged all conflict resolutions. I would find it useful for it to stay
visible in that case, until I continue the rebase.

-Stefan