Re: When exactly should REBASE_HEAD exist?

From: Stefan Haller <lists@haller-berlin.de>
Date: Mar 8, 2023, 19:02 UTC
Message-ID: <4d13d02a-ddaf-7b8f-7a27-c7a030816523@haller-berlin.de>
In-Reply-To: <18763465-de3b-7e64-129b-1f9337ea1924@dunelm.org.uk>

On 05.03.23 21:15, Phillip Wood wrote:

Show 76 quoted lines

> Hi Stefan
> 
> On 05/03/2023 19:13, Stefan Haller wrote:
>> 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...)
> 
> I meant you could just use the done file to get the last command, there
> is no need to look at REBASE_HEAD.

OK, I see. Sounds like a possible algorithm could be:

func commitNameToShowAsTheCurrentlyConflictingCommit() {
    lastDone := last command of "done" file
    if lastDone.command is "break" or "exec" {
        return nil
    }

    next := first command of "git-rebase-todo" file
    if lastDone == next {
        // Command was rescheduled and shows in remaining todos already
        return nil
    }

    if lastDone.command is "edit" {
        if "amend" file exists {
            // "edit" command was successful
            return nil
        }
    }

    return lastDone.commitName
}

Does this sound reasonable?

-Stefan