zlacker

That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.

>>nopurp+(OP)
Yep. I set this in .gitconfig

>>nopurp+(OP)
I came into the comments specifically to ask if this flag existed. I feel bad that the author developed this whole flow just because they didn't know about this, but that's pretty common with git.

>>nopurp+(OP)
I'm guilty lol. I wrote a helper to do rebase chains like this

>>happyt+s9
I'm pretty sure the author was Claude, so don't feel too bad for it.

>>nopurp+(OP)
Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years.

I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.

>>onioni+Nu
discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.

>>nopurp+8w
I plan to pay it forward today with a post on my work slack. I just need to try it a time or two myself first.

>>duskdo+tc
update-refs works only in a narrow case when every branch starts form the tip of a previous. Your helper might still be useful if it properly "replants" whole tree keeping its structure.

>>nopurp+(OP)
Exactly, I was reading the blog and wondering the whole time how it's better than --update-refs, which I have been using a lot recently.

>>nopurp+7x
Though at that point it may be easier to rewrite your helper to manage rebase's interactive scripts.

>>nopurp+8w
Except they do. You can type <tab>, search the man page or read the release notes. They just don't force the user to.

>>nopurp+7x
No, as far as I can tell, it's basically just doing update-refs. But in my defense, I just found out by looking for the option that for some reason my git manpages are from an old version before it was introduced