Re: [PATCH v2] checkout & worktree: introduce checkout.implicitRemote

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, May 3, 2018 at 9:18 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> Introduce a checkout.implicitRemote setting which can be used to
> designate a remote to prefer (via checkout.implicitRemote=origin) when
> running e.g. "git checkout master" to mean origin/master, even though
> there's other remotes that have the "master" branch.
> [...]
> The new checkout.implicitRemote config allows me to say that whenever
> that ambiguity comes up I'd like to prefer "origin", and it'll still
> work as though the only remote I had was "origin".
> [...]
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -1084,6 +1084,23 @@ browser.<tool>.path::
> +checkout.implicitRemote::
> +       When you run 'git checkout <something>' and only have one
> +       remote, it may implicitly fall back on checking out and
> +       tracking e.g. 'origin/<something>'. This stops working as soon
> +       as you have more than one remote with a '<something>'
> +       reference. This setting allows for setting the name of a
> +       special remote that should always win when it comes to

"special" is overly broad. "preferred" may better convey the intended
meaning. Simply dropping "special" also works.

Subjective; not worth a re-roll.

> +       disambiguation. The typical use-case is to set this to
> +       `origin`.
> ++
> +Currently this is used by linkgit:git-checkout[1] when 'git checkout
> +<something>' will checkout the '<something>' branch on another remote,
> +and by linkgit:git-worktree[1] when 'git worktree add' when referring

"when ... when"?

> +to a remote branch.  This setting might be used for other
> +checkout-like commands or functionality in the future when
> +appropriate.

Not sure the final sentence adds value as user-facing documentation
(versus the commit message in which it may).

> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -60,6 +60,11 @@ with a matching name, treat as equivalent to:
>  $ git worktree add --track -b <branch> <path> <remote>/<branch>
> +It's also possible to use the `checkout.implicitRemote` setting to
> +designate a special remote this rule should be applied to, even if the

Again, you could drop "special".

> +branch isn't unique across all remotes. See `checkout.implicitRemote`
> +in linkgit:git-config[1].

I have a hard time digesting this paragraph. Perhaps it wants to say:

    Option `checkout.implicitRemote` can be configured to designate a
    <remote> to use when <branch> isn't unique across all remotes.
    See ...

> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> @@ -450,6 +450,24 @@ test_expect_success 'git worktree --no-guess-remote option overrides config' '
> +test_expect_success '"add" <path> <branch> dwims with checkout.implicitRemote' '
> +       test_when_finished rm -rf repo_upstream repo_dwim foo &&
> +       setup_remote_repo repo_upstream repo_dwim &&
> +       git init repo_dwim &&

Maybe replace "dwim" here and in the test title with something else
since checkout.implicitRemote is no longer about DWIM'ing?

> +       (
> +               cd repo_dwim &&
> +               git remote add repo_upstream2 ../repo_upstream &&
> +               git fetch repo_upstream2 &&
> +               test_must_fail git worktree add ../foo foo &&
> +               git -c checkout.implicitRemote=repo_upstream worktree add ../foo foo
> +       ) &&
> +       (
> +               cd foo &&
> +               test_branch_upstream foo repo_upstream foo &&
> +               test_cmp_rev refs/remotes/repo_upstream/foo refs/heads/foo
> +       )
> +'