Re: Should --update-refs exclude refs pointing to the current HEAD?

[Felipe Contreras <felipe.contreras@gmail.com>]

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