Re: When exactly should REBASE_HEAD exist?

> 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...)