Stefan Haller wrote: > On 17.04.23 10:34, Kristoffer Haugsbakk wrote: > > On Mon, Apr 17, 2023, at 10:21, Stefan Haller wrote: > >> 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. > > > > I would use a lightweight tag, too, since this option doesn’t touch tags.[1] > > > > Why do you want to keep both branches around? > > Several reasons: > > Maybe the original branch was pushed already, and I'm collaborating on > it with a coworker. At the same time, I want to run my rebase experiment > in parallel on a copy. > > Maybe I want to create github PRs for both of them, in order to run CI > on them, or get feedback for both of them from my coworkers. > > Also, it just seems to be the most natural workflow for many people. I > have seen my coworkers do this a lot without thinking much whether there > would be a better way. I also do this, however, I often create a new branch to point to the previous one (`git branch foo-1`). I know I can refer to it with `foo@{1}`, but then I have to keep track if I rebase more than once, or do any other reflog operation. If I've sent the series for review with my tool `git send-series`, then I don't have to worry about that because I have refs for every version I sent. A notion of branch versions really comes in handy. Cheers. -- Felipe Contreras