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.

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

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.

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.

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.

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

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.

Yep. I set this in .gitconfig

I'm guilty lol. I wrote a helper to do rebase chains like this

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.

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

Though at that point it may be easier to rewrite your helper to manage rebase's interactive scripts.