Re: [PATCH] rebase: introduce --update-branches option

[Taylor Blau <me@ttaylorr.com>]

Hi Junio,

On Mon, Sep 02, 2019 at 06:21:33PM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > I like the idea of using existing tooling for this and not needing an
> > additional verb.
> >
> > My gut tells me folks may want a bit more control over *which* branches
> > are rebased, but I don't have a personal need for that, so I'm not going
> > to request it or propose an interface for it.
>
> FWIW, I am in favor of both of the above two points.  It is quite
> clear because "exec git branch -f <that branch name>" is spelled
> out, people can remove the ones they want to keep a copy of when
> they need to.

I agree with what you're saying here. I don't see myself having a need
to modify the 'exec git branch -f ...' line, so I have no real need to
make an interface suggestion per brian's comment above, but I happened
to think of one while reading this thread that seemed worth pointing
out.

Perhaps we could avoid inserting the 'exec git branch -f' step in the
todo list for branches that have a configuration section forbidding them
from being updated?

For example, the configuration:

  [branch "dont-update-me"]
    updateAfterRebase = false

would cause the rebase of a branch upstream from 'dont-update-me' to
omit the 'git branch -f dont-update-me'.

To be honest, this configuration option seems like a knob we don't need.
Especially since now three of us feel that removing the 'exec' line
suffices anyway. I suppose that I could see a user wanting some
integration branch to not get updated over many rebases, but it seems a
little contrived.

Anyway, perhaps others can chime in and share what they think about this
interface and whether or not we need it. If not, we can simply file this
away.

> I didn't look at the code more deeply than just eyeballing and
> noticing style violations etc., and will leave the reviewing to
> others for now.
>
> Thanks.

Thanks,
Taylor