On Mon, Aug 02, 2021 at 15:02:41 +0200, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Jul 28 2021, Ben Boeckel wrote:
> > The `branch.autoSetupMerge` works well today for setting up tracking a
> > local branch, but there is no easy mechanism to automatically set up a
> > remote tracking situation for workflows which use a single set of
> > branches for integration without specifying `--track` to every branch
> > creation command or branching directly from the remote ref. This patch
> > adds the following configuration values:
> >
> > - `branch.defaultRemote`: initializes `branch.<name>.remote` if not
> > otherwise given;
> > - `branch.defaultMerge`: initializes `branch.<name>.merge` if not
> > otherwise given.
>
> Not a new issue per-se, but what if you've got a branch called
> defaultRemote? It seems to me that any new branch.<name>.* config closes
> the door for a <name> we squat on.
It doesn't seem that shadowing is actually a thing:
% git init
Initialized empty Git repository in …/git-shadow/.git/
% git config foo.bar true
% git config foo.bar.baz true
% git config --get foo.bar
true
% git config --get foo.bar.baz
true
> Given that we have checkout.defaultRemote and this also affects
> switch/checkout it seems better to continue in the checkout.* namespace
> even if it wasn't for that, but given the config squatting issue
> especially so....
>
> For what it's worth I usually use the checkout.defaultRemote option
> (which I added) and:
>
> git checkout master &&
> git branch -m master <topic-name>
>
> See 8d7b558baeb (checkout & worktree: introduce checkout.defaultRemote,
> 2018-06-05). It seems to me from that patch diff that you could modify
> some docs / tests for this, no? E.g. how it interacts with git-worktree.
I think it would be weird for `checkout.*` to affect `git branch` which
does no checkout at all. I want it to set up for simple branch creation
as well, so this would be a hole in my use case.
> I like this direction, but just have a concern that this is a place
> where we need to consider all the UX in the area overall, and that any
> options/config don't overtly interact in a bad way.
I'll have to look at adding test cases as to how it interacts with
`checkout.defaultRemote`.
Thanks,
--Ben
