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
