On 05.03.23 21:15, Phillip Wood wrote:
> 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.
OK, I see. Sounds like a possible algorithm could be:
func commitNameToShowAsTheCurrentlyConflictingCommit() {
lastDone := last command of "done" file
if lastDone.command is "break" or "exec" {
return nil
}
next := first command of "git-rebase-todo" file
if lastDone == next {
// Command was rescheduled and shows in remaining todos already
return nil
}
if lastDone.command is "edit" {
if "amend" file exists {
// "edit" command was successful
return nil
}
}
return lastDone.commitName
}
Does this sound reasonable?
-Stefan
