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