Re: When exactly should REBASE_HEAD exist?
- From
- Stefan Haller <lists@haller-berlin.de>
- Date
- Mar 3, 2023, 10:57 UTC
- Message-ID
- <c237c1e3-5cd0-503d-ff4b-96f645a659f3@haller-berlin.de>
- In-Reply-To
- <f28bb5a7-ec68-dce2-9b63-7bfb5330c33e@haller-berlin.de>
On 02.03.23 21:27, Stefan Haller wrote:
Show 30 quoted lines
> 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.
It seems that I can get close by checking whether the file .git/rebase-merge/amend exists. If it does, the current patch was applied already, and I don't show the fake entry. If it doesn't, we still need to commit the changes from REBASE-HEAD, so it makes sense to show it in the list.
Does this sound like a reasonable approach? I must admit that the code in sequencer.c is too complex for me to tell at a glance whether there are situations where this heuristic would do the wrong thing.
-Stefan