On 17.04.23 10:21, Stefan Haller wrote: > 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. One question then is whether the behavior makes sense for the case where you have a stack of branches, and you make a copy of the topmost one and then do either of the two above scenarios with that copy. With my proposal it would leave the old top of the stack alone, but it *would* update all the inner branches of the stack. Whether that's desired or not is very unclear to me, and I would leave it up to user to add --no-update-refs in this case if they don't want it. -Stefan
