Re: When exactly should REBASE_HEAD exist?

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

On 05.03.23 17:59, Stefan Haller wrote:
> On 05.03.23 15:31, Phillip Wood wrote:
>> Hi Stefan
>>
>> On 02/03/2023 20: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.
>>
>> I've not used lazygit but looking at the github page it seems that it is
>> a persistent process that runs "git rebase". If that's the case I would
>> think that you can check for conflicts when the rebase stops and keep
>> that value in memory until the rebase is started again.
> 
> I had considered that, but it would be preferable if it were possible to
> quit lazygit, start it again, and have it show the same state again. Or
> even start the rebase outside of lazygit while it isn't running at all,
> and then start it and have it display the correct state.
> 
>> I think your best bet might be to read "$(git rev-parse --git-path
>> rebase-merge/done)" the last line of which contains the last todo
>> command the rebase tried to execute.
> 
> I'm not sure I understand; you mean in order to distinguish whether it
> was a pick or a fixup?

OK, I guess it's something like

show_fake_entry :=
  REBASE_HEAD exists
  && (last command in "done" file was not "edit"
      || "amend" file exists)

Is that what you meant? (Minus the bit about rescheduling failed
commands, which I still need to wrap my head around...)

-Stefan