git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Jeff King <peff@peff.net>,
	 Yasushi SHOJI <yasushi.shoji@gmail.com>,
	Denton Liu <liu.denton@gmail.com>,
	 Git Mailing List <git@vger.kernel.org>
Subject: Re: Segfault: git show-branch --reflog refs/pullreqs/1
Date: Thu, 22 Feb 2024 08:32:06 -0800	[thread overview]
Message-ID: <xmqq34tkiho9.fsf@gitster.g> (raw)
In-Reply-To: <ZdcNtxw04MtybTWZ@tanuki> (Patrick Steinhardt's message of "Thu, 22 Feb 2024 10:02:47 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>> Even though it may feel wrong to successfully resolve foo@{0} when
>> reflog for foo does not exist at the mechanical level (read: the
>> implementors of reflog mechanism may find the usability hack a bad
>> idea), I suspect at the end-user level it may be closer to what
>> people expect out of foo@{0} (i.e. "give me the latest").
>
> Hum, I dunno. I don't really understand what the benefit of this
> fallback is. If a user wants to know the latest object ID of the ref
> they shouldn't ask for `foo@{0}`, they should ask for `foo`. On the
> other hand, if I want to know "What is the latest entry in the ref's
> log", I want to ask for `foo@{0}`.

The usability hack helps small things like "List up to 4 most recent
states from a branch", e.g.

    for nth in $(seq 0 3)
    do
	git rev-parse --quiet --verify @$nth || break
	git show -s --format="@$nth %h %s" @$nth
    done

vs

    for rev in HEAD @{1} @{2} @{3}
    do
	git rev-parse --quiet --verify "$rev" || break
	git show -s --format="$rev %h %s" "$rev"
    done

by not forcing you to special case the "current".

Ideally, "foo@{0}" should have meant "the state immediately before
the current state of foo" so that "foo" is the unambiguous and only
way to refer to "the current state of foo", but that was not how we
implemented the reflog, allowing a subtle repository corruption
where the latest state of a branch according to the reflog and the
current commit pointed by the branch can diverge.  But that wasn't
what we did, and instead both "foo@{0}" and "foo" mean to refer to
"the latest state of foo".  We can take advantage of that misdesign
and allow "foo@{0}" to refer to the same commit as "foo", at least
at the get_oid_basic() level, whether a reflog actually exists or
not, and that would make the whole thing more consistent.

In any case, I do not know how this "usability" actually helps in
the field, and I wouldn't personally shed tears if it gets removed.
The above is just an explanation why it exists.

Thanks.

  reply	other threads:[~2024-02-22 16:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  1:48 Segfault: git show-branch --reflog refs/pullreqs/1 Yasushi SHOJI
2024-02-21  8:42 ` Jeff King
2024-02-21 10:05   ` Patrick Steinhardt
2024-02-21 17:38     ` Jeff King
2024-02-21 17:44   ` Junio C Hamano
2024-02-22  9:02     ` Patrick Steinhardt
2024-02-22 16:32       ` Junio C Hamano [this message]
2024-02-22 17:22         ` Jeff King
2024-02-26 10:00           ` [PATCH 0/3] show-branch --reflog fixes Jeff King
2024-02-26 10:02             ` [PATCH 1/3] Revert "refs: allow @{n} to work with n-sized reflog" Jeff King
2024-02-26 10:04             ` [PATCH 2/3] get_oid_basic(): special-case ref@{n} for oldest reflog entry Jeff King
2024-02-26 15:59               ` Junio C Hamano
2024-02-26 10:08             ` [PATCH 3/3] read_ref_at(): special-case ref@{0} for an empty reflog Jeff King
2024-02-26 10:10               ` Jeff King
2024-02-26 17:25                 ` Junio C Hamano
2024-02-27  8:07                   ` Jeff King
2024-02-26 17:25               ` Junio C Hamano
2024-02-27  8:05                 ` Jeff King
2024-02-27 17:03                   ` Junio C Hamano
2024-02-21  9:52 ` Segfault: git show-branch --reflog refs/pullreqs/1 Patrick Steinhardt
2024-02-21  9:56 ` [PATCH 0/2] Detect empty or missing reflogs with `ref@{0}` Patrick Steinhardt
2024-02-21  9:56   ` [PATCH 1/2] object-name: detect and report empty reflogs Patrick Steinhardt
2024-02-21 10:37     ` Kristoffer Haugsbakk
2024-02-21 16:48     ` Eric Sunshine
2024-02-21 17:31     ` Jeff King
2024-02-21  9:56   ` [PATCH 2/2] builtin/show-branch: detect " Patrick Steinhardt
2024-02-21 17:35     ` Jeff King

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

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

  git send-email \
    --in-reply-to=xmqq34tkiho9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=liu.denton@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=yasushi.shoji@gmail.com \
    /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.
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 NNTP newsgroup(s).