Re: [PATCH 1/1] config: support a default remote tracking setup upon branch creation

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Aug 2, 2021, 15:20 UTC
Message-ID: <87k0l3oo38.fsf@evledraar.gmail.com>
In-Reply-To: <YQfwJOxlBOUWiH1V@erythro.dev.benboeckel.internal>

On Mon, Aug 02 2021, Ben Boeckel wrote:

Show 28 quoted lines

> 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

You're right, I was misrecalling (or mis-imagining) some edge case there that doesn't exist. I also tested setting branch.defaultRemote=true and moving a branch.defaultRemote.* branch with "git branch -m", but it also does the right thing. Nevermind.

Show 18 quoted lines

>> 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.

*nod*, although your approach has the opposite problem of making branch creation with "checkout" and "switch" (and presumably "worktree") impacted by "branch.*' config.

In a way that's more sensible, in that we can imagine those commands calling "git branch" under the hood (which msotly doesn't actually happen, except I think in the worktree case, but it's the same underlying APIs).

..

Show 8 quoted lines

>> 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,

....right, none of that mess is a showstopper, I'm just prodding you to look at if any of those edge cases are made better/worse by these additions. Thanks!