From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Lohmann <mi.al.lohmann@gmail.com>,
git@vger.kernel.org, newren@gmail.com, phillip.wood123@gmail.com
Subject: Re: [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge
Date: Mon, 15 Jan 2024 12:36:40 +0100 [thread overview]
Message-ID: <ZaUYyEAdr4oTImL-@tanuki> (raw)
In-Reply-To: <xmqqzfxa9usx.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]
On Fri, Jan 12, 2024 at 12:10:54PM -0800, Junio C Hamano wrote:
> Michael Lohmann <mi.al.lohmann@gmail.com> writes:
>
> >> but we may want to tighten the original's use of repo_get
> >> > - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> >> > - die("--merge without MERGE_HEAD?");
> >> > - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
> >>
> >> ... so that we won't be confused in a repository that has a tag
> >> whose name happens to be MERGE_HEAD. We probably should be using
> >> refs.c:refs_resolve_ref_unsafe() instead to _oid() here ...
> >
> > Here I am really at the limit of my understanding of the core functions.
> > Is this roughly what you had in mind? From my testing it seems to do the
> > job, but I don't understand the details "refs_resolve_ref_unsafe"...
>
> Perhaps there are others who are more familiar with the ref API than
> I am, but I was just looking at refs.h today and wonder if something
> along the lines of this ...
>
> if (read_ref_full("MERGE_HEAD",
> RESOLVE_REF_READING | RESOLVE_REF_NO_RECURSE,
> &oid, NULL))
> die("no MERGE_HEAD");
> if (is_null_oid(&oid))
> die("MERGE_HEAD is a symbolic ref???");
>
> ... would be simpler.
>
> With the above, we are discarding the refname read_ref_full()
> obtains from its refs_resolve_ref_unsafe(), but I think that is
> totally fine. We expect it to be "MERGE_HEAD" in the good case.
> The returned value can be different from "MERGE_HEAD" if it is
> a symbolic ref, but if the comment in refs.h on NO_RECURSE is to be
> trusted, we should catch that case with the NULL-ness check on oid.
Yeah, this should be fine.
Even though I have stared at our refs API for extended periods of time
during the last months I still have to look up this part of the API
almost every time. I find it to be hard to use because you not only have
to pay attention to the return value, but also to the flags in some edge
cases. I wouldn't be surprised if there were many callsites that get
this wrong.
> Which would mean that we do not need a separate "other_head"
> variable, and instead can use "MERGE_HEAD".
There is no need for this, is there? We have already resolved the ref to
an object ID, so why not use that via `add_pending_oid()`?
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-15 11:36 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 23:33 [RFC PATCH] `log --merge` also for rebase/cherry pick/revert Michael Lohmann
2024-01-12 0:15 ` Junio C Hamano
2024-01-12 15:50 ` [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Michael Lohmann
2024-01-12 15:50 ` [PATCH v2 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Michael Lohmann
2024-01-12 20:10 ` [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Junio C Hamano
2024-01-15 11:36 ` Patrick Steinhardt [this message]
2024-01-15 17:19 ` Junio C Hamano
2024-01-17 8:14 ` [PATCH v3 " Michael Lohmann
2024-01-17 8:14 ` [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Michael Lohmann
2024-01-17 9:19 ` Full disclosure Michael Lohmann
2024-01-17 9:58 ` Christian Couder
2024-01-17 17:41 ` Michael Lohmann
2024-01-21 0:41 ` Ruben Safir
2024-01-17 18:33 ` Junio C Hamano
2024-01-24 7:06 ` [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Elijah Newren
2024-01-24 17:19 ` Johannes Sixt
2024-01-24 19:46 ` Junio C Hamano
2024-01-24 22:06 ` Johannes Sixt
2024-01-24 22:13 ` Junio C Hamano
2024-02-09 23:54 ` Junio C Hamano
2024-01-24 17:34 ` Junio C Hamano
2024-02-10 23:35 ` [PATCH v4 0/2] Implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-10 23:35 ` [PATCH v4 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-10 23:35 ` [PATCH v4 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-11 8:34 ` Johannes Sixt
2024-02-11 16:43 ` Philippe Blain
2024-02-11 17:59 ` Johannes Sixt
2024-02-12 18:27 ` Junio C Hamano
2024-02-12 11:02 ` Phillip Wood
2024-02-13 13:27 ` Philippe Blain
2024-02-14 11:02 ` Phillip Wood
2024-02-13 8:33 ` Jean-Noël Avila
2024-02-13 13:14 ` Philippe Blain
2024-02-25 21:56 ` [PATCH v5 0/2] Implement " Philippe Blain
2024-02-25 21:56 ` [PATCH v5 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-26 17:22 ` Jean-Noël Avila
2024-02-26 17:54 ` Philippe Blain
2024-02-25 21:56 ` [PATCH v5 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-26 4:35 ` Junio C Hamano
2024-02-26 17:43 ` Philippe Blain
2024-02-27 14:00 ` [PATCH v5 0/2] Implement " Phillip Wood
2024-02-27 18:30 ` Junio C Hamano
2024-02-28 13:54 ` [PATCH v6 " Philippe Blain
2024-02-28 13:54 ` [PATCH v6 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-28 13:54 ` [PATCH v6 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-28 14:40 ` [PATCH v6 0/2] Implement " phillip.wood123
2024-03-02 15:35 ` Philippe Blain
2024-01-12 7:35 ` [RFC PATCH] `log --merge` also for rebase/cherry pick/revert Johannes Sixt
2024-01-12 7:59 ` Johannes Sixt
2024-01-12 20:18 ` Junio C Hamano
2024-01-12 11:01 ` phillip.wood123
2024-01-12 15:03 ` Michael Lohmann
2024-01-12 21:14 ` Junio C Hamano
2024-01-15 10:48 ` Phillip Wood
2024-01-12 20:21 ` Junio C Hamano
2024-01-12 21:06 ` Michael Lohmann
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=ZaUYyEAdr4oTImL-@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mi.al.lohmann@gmail.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@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).