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