From: Phillip Wood Date: Sun, 05 Mar 2023 14:33:30 GMT Subject: Re: When exactly should REBASE_HEAD exist? Message-ID: <65f9d6c3-d7eb-5059-74d1-b9c150ddcccf@dunelm.org.uk> In-Reply-To: Hi Stefan On 03/03/2023 10:57, Stefan Haller wrote: > On 02.03.23 21: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. > > It seems that I can get close by checking whether the file > .git/rebase-merge/amend exists. If it does, the current patch was > applied already, and I don't show the fake entry. If it doesn't, we > still need to commit the changes from REBASE-HEAD, so it makes sense to > show it in the list. > > Does this sound like a reasonable approach? I must admit that the code > in sequencer.c is too complex for me to tell at a glance whether there > are situations where this heuristic would do the wrong thing. When a fixup or squash stops for a confict resolution that file also exists as the result needs to be squashed into HEAD. Best Wishes Phillip