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.
next prev parent 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).