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