Hi Stefan
On 05/03/2023 19:13, Stefan Haller wrote:
On 05.03.23 17:59, Stefan Haller wrote:
On 05.03.23 15:31, Phillip Wood wrote:
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.
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?
OK, I guess it's something like
show_fake_entry :=
REBASE_HEAD exists
&& (last command in "done" file was not "edit"
|| "amend" file exists)
Is that what you meant? (Minus the bit about rescheduling failed
commands, which I still need to wrap my head around...)
I meant you could just use the done file to get the last command, there
is no need to look at REBASE_HEAD.
Best Wishes
Phillip
-Stefan
