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, 13:02 UTC
Message-ID: <87sfzsngad.fsf@evledraar.gmail.com>
In-Reply-To: <20210729020125.746206-2-mathstuf@gmail.com>

On Wed, Jul 28 2021, Ben Boeckel wrote:

Show 11 quoted lines

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

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