Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 02 2018, Eric Sunshine wrote:

On Wed, May 2, 2018 at 11:21 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

quoted

Introduce a core.DWIMRemote setting which can be used to designate a
remote to prefer (via core.DWIMRemote=origin) when running e.g. "git
checkout master" to mean origin/master, even though there's other
remotes that have the "master" branch.

Do we anticipate more dwimy customizations to justify a new dwim group
in config (i.e. dwim.remote instead of core.dwimRemote)?

A few observations:

1. DWIM has broad meaning; while this certainly falls within DWIM,
it's also just a _default_, so should this instead be named
"defaultRemote"?

2. Building on #1: How well is the term "DWIM" understood by non-power
users? A term, such as "default" is more well known.

I've got no love for the DWIM term. And I think I should change it in
v2, I just want some way to enable this functionality since this
behavior has annoyed me for a long time.

I wonder though if something like "core.defaultRemote" might not bring
up connotations about whether this would e.g. affect "push" in the minds
of users (not that my initial suggestion is better).

So maybe something like checkout.implicitRemote would be better? And we
could just break the rule that only git-checkout would use it, since
git-worktree could be said to be doing something checkout-like, or just
also add a worktree.implicitRemote.

3. git-worktree learned --guess-remote and worktree.guessRemote in [1]
and [2], which, on the surface, sound confusingly similar to
"DWIMRemote". Even though I was well involved in the discussion and
repeatedly reviewed the patch series which introduced those, it still
took me an embarrassingly long time, and repeated re-reads of all
commit messages involved, to grasp (or re-grasp) how "guess remote"
and "DWIM remote" differ. If it was that difficult for me, as a person
involved in the patch series, to figure out "guess remote" vs. "DWIM
remote", then I worry that it may be too confusing in general. If the
new config option had been named "defaultRemote", I don't think I'd
have been confused at all.

I hadn't looked at this at all before today when I wrote the patch, and
I've never used git-worktree (but maybe I should...), but my
understanding of this --[no-]guess-remote functionality is that it
effectively splits up the functionality that the "git checkout" does,
and we'll unconditionally check out the branch, but the option controls
whether or not we'd set up the equivalent of remote tracking for
git-worktree.

But maybe I've completely misunderstood it.

It may sound as if I'm advocating the name "defaultRemote", but that
wasn't the intention, and I'm not wedded to it; that name simply fell
out naturally as I enumerated the above observations.

[1]: 71d6682d8c (worktree: add --guess-remote flag to add subcommand,
2017-11-29)
[2]: e92445a731 (add worktree.guessRemote config option, 2017-11-29)