On 02.03.23 11:19, Phillip Wood wrote: > On 28/02/2023 12:55, Stefan Haller wrote: >> As far as I can tell, REBASE_HEAD always points to the last commit that >> was attempted to be applied in a rebase, not matter whether that attempt >> was successful or not. In other words, when you break in a rebase with >> "edit" or "break", REBASE_HEAD is the same as HEAD > > As you said at the beginning REBASE_HEAD points to the commit that we're > trying to pick, so it will only be the same as HEAD if the pick was > successful and it was not rebased onto a new parent. Right, I was a bit sloppy in describing the current behavior. > I think it is > useful to have REBASE_HEAD set when editing a commit as I find it is > sometimes useful to look at the original commit. OK. >> 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. -Stefan
