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

Re: Should --update-refs exclude refs pointing to the current HEAD?

From
SHStefan Haller <lists@haller-berlin.de>
Date
Mar 5, 2024, 07:40 UTC
Message-ID
<354f9fed-567f-42c8-9da9-148a5e223022@haller-berlin.de>
In-Reply-To
<adb7f680-5bfa-6fa5-6d8a-61323fee7f53@haller-berlin.de>
On 17.04.23 10:21, Stefan Haller wrote:
Show 23 quoted lines
> The --update-refs option of git rebase is so useful that I have it on by
> default in my config. For stacked branches I find it hard to think of
> scenarios where I wouldn't want it.
> 
> However, there are cases for non-stacked branches (i.e. other branches
> pointing at the current HEAD) where updating them is undesirable. In
> fact, pretty much always, for me. Two examples, both very similar:
> 
> 1. I have a topic branch which is based off of master; I want to make a
> copy of that branch and rebase it onto devel, just to try if that would
> work. I don't want the original branch to be moved along in this case.
> 
> 2. I have a topic branch, and I want to make a copy of it to make some
> heavy history rewriting experiments. Again, my interactive rebases would
> always rebase both branches in the same way, not what I want. In this
> case I could work around it by doing the experiments on the original
> branch, creating a tag beforehand that I could reset back to if the
> experiments fail. But maybe I do want to keep both branches around for a
> while for some reason.
> 
> Both of these cases could be fixed by --update-refs not touching any
> refs that point to the current HEAD. I'm having a hard time coming up
> with cases where you would ever want those to be updated, in fact.

Coming back to this after almost a year, I can say that I'm still running into this problem relatively frequently, and it is annoying every single time. Excluding refs pointing at the current head from being updated, as proposed above, would be a big usability improvement for me.

And I now see that "git replay --contained --onto" has the same problem, which I find very unfortunate. In my opinion, "contained" should only include refs that form a stack, but not copies of the current branch.

Of course, since branch stacks are only a heuristic and not a built-in concept, it's impossible for git to distinguish between a pair of copied branches and a degenerate stack whose top-most branch is (still) empty, as in the example in [1]. In my personal experience though, degenerate stacks like that are very rare, but copied branches are not, so for me it would make a lot of sense to change the behavior of both "rebase --update-refs" and "replay --contained".

-Stefan
[1] <https://public-inbox.org/git/
     98548a5b-7d30-543b-b943-fd48d8926a33@gmail.com/>
Previous: Stefan HallerNext: Junio C Hamano
Message 8 of 18 in “Should --update-refs exclude refs pointing to the current HEAD?”
  1. Stefan HallerApr 17, 2023
  2. Stefan HallerApr 17, 2023
  3. Kristoffer HaugsbakkApr 17, 2023
  4. Stefan HallerApr 17, 2023
  5. Felipe ContrerasApr 18, 2023
  6. Phillip WoodApr 17, 2023
  7. Stefan HallerApr 20, 2023
  8. Stefan HallerMar 5, 2024
  9. Junio C HamanoMar 5, 2024
  10. Elijah NewrenMar 6, 2024
  11. Stefan HallerMar 6, 2024
  12. Elijah NewrenMar 7, 2024
  13. Stefan HallerMar 7, 2024
  14. Elijah NewrenMar 9, 2024
  15. Stefan HallerMar 12, 2024
  16. Kristoffer HaugsbakkMar 7, 2024
  17. Elijah NewrenMar 7, 2024
  18. Stefan HallerMar 24, 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.