From: Phillip Wood Date: Thu, 02 Mar 2023 10:19:33 GMT Subject: Re: When exactly should REBASE_HEAD exist? Message-ID: <374f83c2-7bf0-38be-26ae-de28340c37d2@dunelm.org.uk> In-Reply-To: <961e68d7-5f43-c385-10fa-455b8e2f32d0@haller-berlin.de> Hi Stefan 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. 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. I don't think we do (or should) set it when rebase stops for a "break" command or a failed "exec" command. >(except when you > break before the first commit, in that case REBASE_HEAD is unset). > > I wonder whether it would make sense to set REBASE_HEAD only when > applying a patch failed. That seems to be the main use case of it. As I mentioned above, I think having it available when editing a commit us useful. > 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? Best Wishes Phillip > I currently do that by comparing it against HEAD, and only showing it > when they are different. That doesn't always work though, e.g. when I > amend the current "edit" commit. > > Any better suggestions how to work around this? > > -Stefan >