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

Re: [PATCH 2/2] fetch: add branch.*.merge to default ref-prefix extension

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 9, 2022, 05:23 UTC
Message-ID
<xmqqv8pxm880.fsf@gitster.g>
In-Reply-To
<YxqiJW4cSp4cBR22@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> The code in fetch's add_merge_config() that does branch_merge_matches()
> comes from 85682c1903 (Correct handling of branch.$name.merge in
> builtin-fetch, 2007-09-18), but I don't see any indication there that
> non-qualified refs were intended.
>
> So I could either way: non-qualified refs in branch.*.merge has always
> worked, and we should continue to support it. Or it was never intended
> to work, and we are not obligated to continue supporting random things.

Yeah, it looks like it was working by accident. I do not care too deeply about folks who edit their configuration files to futz with branch.<name>.merge, and "checkout -t -b" and "branch -t" commands have been recording only full refs, so it is tempting to tighten branch_merge_matches() to only allow full refname. The only thing that makes me hesitate to start writing code to do so is that some third-party tools might have taken advantage of the fact that using a branch-name was "working" by accident.

Show 5 quoted lines
> I do think "continue supporting" would probably just mean using
> expand_ref_prefix() here as you suggest. It does increase the size of
> our request, and the work the server has to do when it matches the
> prefixes (which is inherently linear on the number of prefixes we give
> it).

Giving extra garbage to the set of prefixes does not hurt the correctness, but we didn't add the extra prefix for branch.<name>.merge before this fix, so not using expand_ref_prefix() is not breaking anybody who weren't broken before. So I think it may be OK to support only the full refs at first. It's just that folks who didn't have full refname as the value is not helped by our fix.

If enough folks complain that they have handcrafted (or prepared by third-party tools) branch.<name>.merge that is not a full refname, we could switch to expand_ref_prefix() and as long as the refnames on the remote side is not ambiguous, things will still work correctly, but I'd prefer to keep it tight until we actually hear complaints.

Thanks.
Previous: Jeff KingNext: Jeff King
Message 22 of 31 in “2.37.2 can't "git pull" but 2.18.0 can”
  1. Lana DeereSep 2, 2022
  2. brian m. carlsonSep 2, 2022
  3. Lana DeereSep 6, 2022
  4. Johannes SchindelinSep 7, 2022
  5. Lana DeereSep 7, 2022
  6. Jeff KingSep 8, 2022
  7. Jeff KingSep 3, 2022
  8. Lana DeereSep 6, 2022
  9. Đoàn Trần Công DanhSep 7, 2022
  10. Lana DeereSep 7, 2022
  11. Jeff KingSep 7, 2022
  12. Lana DeereSep 7, 2022
  13. Jeff KingSep 7, 2022
  14. Lana DeereSep 8, 2022
  15. Jeff KingSep 8, 2022
  16. 0/2 v2 protocol can't "git pull" with restricted refspecJeff King, Sep 8, 2022
  17. 1/2 fetch: stop checking for NULL transport->remote in do_fetch()Jeff King, Sep 8, 2022
  18. 2/2 fetch: add branch.*.merge to default ref-prefix extensionJeff King, Sep 8, 2022
  19. Junio C HamanoSep 8, 2022
  20. Junio C HamanoSep 8, 2022
  21. Jeff KingSep 9, 2022
  22. Junio C HamanoSep 9, 2022
  23. Jeff KingSep 11, 2022
  24. Lana DeereSep 9, 2022
  25. Junio C HamanoSep 9, 2022
  26. Lana DeereSep 12, 2022
  27. Jeff KingSep 13, 2022
  28. Johannes SchindelinSep 5, 2022
  29. Lana DeereSep 6, 2022
  30. Johannes SchindelinSep 7, 2022
  31. Lana DeereSep 7, 2022

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.