From: Phillip Wood Date: Sun, 05 Mar 2023 20:15:23 GMT Subject: Re: When exactly should REBASE_HEAD exist? Message-ID: <18763465-de3b-7e64-129b-1f9337ea1924@dunelm.org.uk> In-Reply-To: <97eec89b-6a10-434a-a9aa-54c266da7fb1@haller-berlin.de> 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. Best Wishes Phillip > -Stefan