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

Re: [PATCH v3 1/2] rebase: skip branch symref aliases

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 26, 2026, 15:42 UTC
Message-ID
<xmqq7bmhycxq.fsf@gitster.g>
In-Reply-To
<00e529b6-7ae7-463f-a4b3-0991e9411aba@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 10 quoted lines
>> Thanks for re-rolling I'm pretty sure the logic is sound now but I'm a 
>> bit confused by a couple of things - see my comments below.
>> ...
>> It would be nice to have a comment here explaining what we're doing. 
>> Also I don't think we need to copy the refname so it would be more 
>> efficient to use refs_resolve_ref_unsafe().
>
> Looking at this again we cannot use refs_resolve_ref_unsafe() because 
> the result would be overwritten by the call to refs_resolve_refdup() in 
> branch_checked_out().

Makes sense. Thanks for raising a possible alternative and then clarifying that it is not quite workable.

Show 18 quoted lines
>>> +        /*
>>> +         * If the branch is the current HEAD, then it will be
>>> +         * updated by the default rebase behavior.
>>> +         */
>>> +        if (head_ref && !strcmp(head_ref, decoration->name)) {
>>> +            free(resolved_ref);
>>>               decoration = decoration->next;
>>>               continue;
>>>           }
>> 
>> Then we check to see if the decoration matches HEAD which we used to do 
>> above - I'm not clear why we have moved this check.
>
> Should we be using "resolved_ref" instead of "decoration->name"? That 
> would explain why this was moved and would makes sense as we resolve 
> symrefs when reading HEAD. When HEAD points outside "refs/heads/" we'd 
> then skip updating any symrefs under "refs/heads/" that pointed to the 
> same ref as HEAD.

Yeah, decoration is very much end-user facing and if we can make behavioural decision based on a more stable resolved_ref that would make it easier to reason about.

But stepping back a bit, is having a HEAD that is a symref and points outside "refs/heads/" an invalid state? Why are we catering to such a configuration to begin with?

Previous: Erik Cervin-EdinNext: Phillip Wood
Message 16 of 25 in “rebase: handle --update-refs branch symrefs”
  1. 0/2 rebase: handle --update-refs branch symrefsSon Luong Ngoc via GitGitGadget, May 28, 2026
  2. 1/2 t3404: add failing branch symref testSon Luong Ngoc via GitGitGadget, May 28, 2026
  3. Phillip WoodJun 1, 2026
  4. 2/2 rebase: skip branch symref aliasesSon Luong Ngoc via GitGitGadget, May 28, 2026
  5. Kristoffer HaugsbakkMay 28, 2026
  6. Phillip WoodJun 1, 2026
  7. Junio C HamanoMay 28, 2026
  8. rebase: skip branch symref aliasesSon Luong Ngoc via GitGitGadget, Jun 3, 2026
  9. Phillip WoodJun 4, 2026
  10. Son Luong NgocJul 22, 2026
  11. 0/2 rebase: handle --update-refs branch symrefsSon Luong Ngoc via GitGitGadget, Jul 22, 2026
  12. 1/2 rebase: skip branch symref aliasesSon Luong Ngoc via GitGitGadget, Jul 22, 2026
  13. Phillip WoodJul 23, 2026
  14. Phillip WoodJul 24, 2026
  15. Erik Cervin-EdinJul 25, 2026
  16. Junio C HamanoJul 26, 2026
  17. Phillip WoodJul 28, 2026
  18. Junio C HamanoJul 28, 2026
  19. Phillip WoodJul 29, 2026
  20. Junio C HamanoJul 29, 2026
  21. Phillip WoodJul 30, 2026
  22. Junio C HamanoAug 6, 2026
  23. Phillip WoodAug 7, 2026
  24. 2/2 rebase: guard non-branch symref targetsSon Luong Ngoc via GitGitGadget, Jul 22, 2026
  25. Phillip WoodAug 7, 2026

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.