Re: When exactly should REBASE_HEAD exist?

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Mar 5, 2023, 14:31 UTC
Message-ID: <db9f3be7-097f-006e-927a-91be7a50360c@dunelm.org.uk>
In-Reply-To: <f28bb5a7-ec68-dce2-9b63-7bfb5330c33e@haller-berlin.de>

Hi Stefan

On 02/03/2023 20:27, Stefan Haller wrote:

Show 30 quoted lines

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

Another thing to bear in mind is that if the commit being picked has already been applied upstream then the rebase will stop without conflicts but you'd want to add the commit being picked to the list in lazygit.

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. Not that failed command are sometimes rescheduled (for example when a pick would overwrite an untracked file) so you'd need to check the first line of "$(git rev-parse --git-path rebase-merge/git-rebase-todo)" as well.

Best Wishes

Phillip

> -Stefan