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
