Re: When exactly should REBASE_HEAD exist?

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

On 02.03.23 21:27, Stefan Haller wrote:
> On 02.03.23 11:19, Phillip Wood wrote:
>> On 28/02/2023 12:55, Stefan Haller wrote:
>>> 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.

It seems that I can get close by checking whether the file
.git/rebase-merge/amend exists. If it does, the current patch was
applied already, and I don't show the fake entry. If it doesn't, we
still need to commit the changes from REBASE-HEAD, so it makes sense to
show it in the list.

Does this sound like a reasonable approach? I must admit that the code
in sequencer.c is too complex for me to tell at a glance whether there
are situations where this heuristic would do the wrong thing.

-Stefan