git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Haller <lists@haller-berlin.de>
To: phillip.wood@dunelm.org.uk, git@vger.kernel.org
Subject: Re: When exactly should REBASE_HEAD exist?
Date: Wed, 8 Mar 2023 20:02:17 +0100	[thread overview]
Message-ID: <4d13d02a-ddaf-7b8f-7a27-c7a030816523@haller-berlin.de> (raw)
In-Reply-To: <18763465-de3b-7e64-129b-1f9337ea1924@dunelm.org.uk>

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

  reply	other threads:[~2023-03-08 19:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 12:55 When exactly should REBASE_HEAD exist? Stefan Haller
2023-03-02 10:19 ` Phillip Wood
2023-03-02 20:27   ` Stefan Haller
2023-03-03 10:57     ` Stefan Haller
2023-03-03 21:25       ` Chris Torek
2023-03-04  8:36         ` Stefan Haller
2023-03-06  3:31           ` Chris Torek
2023-03-07 13:16             ` Stefan Haller
2023-03-05 14:33       ` Phillip Wood
2023-03-05 16:58         ` Stefan Haller
2023-03-05 14:31     ` Phillip Wood
2023-03-05 16:59       ` Stefan Haller
2023-03-05 19:13         ` Stefan Haller
2023-03-05 20:15           ` Phillip Wood
2023-03-08 19:02             ` Stefan Haller [this message]
2023-03-10  9:56               ` Phillip Wood
2023-03-10 17:42                 ` Stefan Haller
2023-03-16 17:46                   ` Phillip Wood
2023-03-19 14:50                     ` Phillip Wood
2023-03-20  7:29                       ` Stefan Haller
2023-03-20  8:42                         ` Stefan Haller
2023-03-07 18:07 ` Junio C Hamano
2023-03-08 19:02   ` Stefan Haller
2023-03-08 19:40     ` Junio C Hamano
2023-03-09 14:45       ` Stefan Haller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d13d02a-ddaf-7b8f-7a27-c7a030816523@haller-berlin.de \
    --to=lists@haller-berlin.de \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).