Re: When exactly should REBASE_HEAD exist?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stefan

On 02/03/2023 20:27, Stefan Haller wrote:
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.

I've not used lazygit but looking at the github page it seems that it is a persistent process that runs "git rebase". If that's the case I would think that you can check for conflicts when the rebase stops and keep that value in memory until the rebase is started again.

Another thing to bear in mind is that if the commit being picked has already been applied upstream then the rebase will stop without conflicts but you'd want to add the commit being picked to the list in lazygit.

I think your best bet might be to read "$(git rev-parse --git-path rebase-merge/done)" the last line of which contains the last todo command the rebase tried to execute. Not that failed command are sometimes rescheduled (for example when a pick would overwrite an untracked file) so you'd need to check the first line of "$(git rev-parse --git-path rebase-merge/git-rebase-todo)" as well.

Best Wishes

Phillip

-Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux