Subject: Re: When exactly should REBASE_HEAD exist?

From: Junio C Hamano <[email-masked]>
Date: Tue, 07 Mar 2023 10:07:30 -0800

Stefan Haller <[email-masked]> writes:

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

Stepping a bit, how does our "git status" fare here?  It shows what
step in a sequence "rebase -i" the user who got control back (due to
"break", "exec sh", "edit" or a conflicted "pick") is in.  Or at
least it tries to.  Does it suffer from the same "great, but ..."?

If it works better than how lazygit shows, perhaps how it computes
the current state can be reproduced, or better yet, the current
state it computed can be exposed, and it can be prototyped by
parsing "LC_ALL=C git status -uno" output, perhaps?