Re: [PATCH 1/4] rebase -i: stop overwriting ORIG_HEAD buffer

From: herr.kaste <herr.kaste@gmail.com>
Date: Nov 3, 2020, 11:02 UTC
Message-ID: <CAFzd1+5D4pHhGf=K0LwaaOUjoBByqsMTpBVtR+Ots6-afBTDEA@mail.gmail.com>
In-Reply-To: <xmqqpn4vqogu.fsf@gitster.c.googlers.com>

Am Di., 3. Nov. 2020 um 01:21 Uhr schrieb Junio C Hamano <gitster@pobox.com>:

Show 16 quoted lines

>
> "herr.kaste" <herr.kaste@gmail.com> writes:
>
> > Phillip pointed out that ORIG_HEAD is actually not save *if* there is
> > a `reset` or `rebase --skip` during the rebase.  Otherwise, by design,
> > ORIG_HEAD would be easier to use, as in the form `<branch_name>@{<n>}`
> > two things have to be decided and can go wrong.
>
> What "two"?  You should be able to just say @{1} regardless---that
> was the whole point of performing all the intermediate steps while
> on the detached HEAD so that you can rely on <n> being 1, and @{<num
> or time>} is a short-hand of <branch>@{<num or time>} for the
> current branch, and not a short-hand for HEAD@{...}, to help such a
> use case.
>
> Or am I missing something?

Well, "@{1}" basically means: from the stream of things that happened take the first. It is very natural to refer to the most recent thing differently. In practice, until now, I used the {...} form only to refer to older things. To put it differently, using {...} I'm researching history.

From the docs:

    ORIG_HEAD is created by commands that move your HEAD in a drastic way,
    to record the position of the HEAD before their operation, so that you
    can easily change the tip of the branch back to the state before you ran
    them.

That's just humane. You do something, and then you revert. I don't need a concept of a written history here, just of recency.