On 05.03.23 15:33, Phillip Wood wrote: > 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. > > When a fixup or squash stops for a confict resolution that file also > exists as the result needs to be squashed into HEAD. Ah damn, yes. And that's even a pretty common situation, so I can't just ignore it as a rare edge case. -Stefan
