On 05.03.23 15:31, Phillip Wood wrote:
Hi Stefan
On 02/03/2023 20:27, Stefan Haller wrote:
quoted
On 02.03.23 11:19, Phillip Wood wrote:
quoted
On 28/02/2023 12:55, Stefan Haller wrote:
quoted
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.
I had considered that, but it would be preferable if it were possible to
quit lazygit, start it again, and have it show the same state again. Or
even start the rebase outside of lazygit while it isn't running at all,
and then start it and have it display the correct state.
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.
I'm not sure I understand; you mean in order to distinguish whether it
was a pick or a fixup?
-Stefan