On Thu, May 3, 2018 at 9:18 AM, Ævar Arnfjörð Bjarmason
<[email protected]> 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 <[email protected]>
> ---
> 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
> + )
> +'
