Re: When exactly should REBASE_HEAD exist?

From: Stefan Haller <lists@haller-berlin.de>
Date: Mar 10, 2023, 17:42 UTC
Message-ID: <805626af-b147-d3cf-5257-a5b90b7cf1d9@haller-berlin.de>
In-Reply-To: <722659e9-02ac-a9d2-b0fd-b9a2a3d85753@dunelm.org.uk>

On 10.03.23 10:56, Phillip Wood wrote:

Show 53 quoted lines

> Hi Stefan
> 
> On 08/03/2023 19:02, Stefan Haller wrote:
>> On 05.03.23 21:15, Phillip Wood wrote:
>>> 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.
>> OK, I see. Sounds like a possible algorithm could be:
>>
>> func commitNameToShowAsTheCurrentlyConflictingCommit() {
> 
> Going back to your original email, if all you want to do is show "YOU
> ARE HERE" against the correct commit then you can get that from the last
> entry in the "done" file irrespective of whether there were conflicts or
> not. If you also want to show whether it was picked cleanly or not then
> it is more complicated.

In my first example above, I'm editing the 2nd commit and it applied cleanly. What I see in that case is

pick   4th commit
pick   3rd commit
       2nd commit  <-- YOU ARE HERE
       1st commit

2nd commit is the current HEAD, which corresponds to the last entry in the "done" file, so there's no reason to display the "done" file entry too in this case.

Only if it wasn't applied cleanly (and wasn't rescheduled) do I want to show the "done" entry. This way I always see four entries in my list, no matter what happened (unless I drop commits, of course), which is what I want.

Show 15 quoted lines

>>      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
>>      }
> 
> I don't know what your current implementation looks like but if I was
> starting from scratch I think it would be simpler to always use the last
> command from "done" and then suppress the first command from
> "git-rebase-todo" if it is the same.

That would also be possible, but in lazygit it makes things harder, because items from "git-rebase-todo" can be interacted with (e.g. moved up or down, or dropped), whereas the "done" entry is only for display purposes and can't be interacted with. That's why I called it a "fake" entry above.

I tried the algorithm now and seems to do exactly what I want, so thanks for the help with this, I'm happy now.

There's a slight correction though: if a command is rescheduled, then git appears to re-append the last successful command to the end of the "done" file (it's in there twice now). So I have to check the second-to-last command of "done" against the first command of "git-rebase-todo" to find out if a command was rescheduled.

-Stefan