git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge

From
Patrick Steinhardt <ps@pks.im>
Date
Jan 15, 2024, 11:36 UTC
Message-ID
<ZaUYyEAdr4oTImL-@tanuki>
In-Reply-To
<xmqqzfxa9usx.fsf@gitster.g>
On Fri, Jan 12, 2024 at 12:10:54PM -0800, Junio C Hamano wrote:
Show 34 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 30 in “`log --merge` also for rebase/cherry pick/revert”
  1. `log --merge` also for rebase/cherry pick/revertMichael Lohmann, Jan 11, 2024
  2. Junio C HamanoJan 12, 2024
  3. 1/2 revision: ensure MERGE_HEAD is a ref in prepare_show_mergeMichael Lohmann, Jan 12, 2024
  4. 2/2 revision: Implement `git log --merge` also for rebase/cherry_pick/revertMichael Lohmann, Jan 12, 2024
  5. Junio C HamanoJan 12, 2024
  6. Patrick SteinhardtJan 15, 2024
  7. Junio C HamanoJan 15, 2024
  8. 1/2 revision: ensure MERGE_HEAD is a ref in prepare_show_mergeMichael Lohmann, Jan 17, 2024
  9. 2/2 revision: Implement `git log --merge` also for rebase/cherry_pick/revertMichael Lohmann, Jan 17, 2024
  10. Full disclosureMichael Lohmann, Jan 17, 2024
  11. Christian CouderJan 17, 2024
  12. Full disclosureMichael Lohmann, Jan 17, 2024
  13. Ruben SafirJan 21, 2024
  14. Junio C HamanoJan 17, 2024
  15. Elijah NewrenJan 24, 2024
  16. Junio C HamanoJan 24, 2024
  17. Johannes SixtJan 24, 2024
  18. Junio C HamanoJan 24, 2024
  19. Johannes SixtJan 24, 2024
  20. Junio C HamanoJan 24, 2024
  21. Junio C HamanoFeb 9, 2024
  22. Johannes SixtJan 12, 2024
  23. Johannes SixtJan 12, 2024
  24. Junio C HamanoJan 12, 2024
  25. phillip.wood123@gmail.comJan 12, 2024
  26. Michael LohmannJan 12, 2024
  27. Junio C HamanoJan 12, 2024
  28. Phillip WoodJan 15, 2024
  29. Junio C HamanoJan 12, 2024
  30. Michael LohmannJan 12, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.