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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, May 02 2018, Eric Sunshine wrote:

> On Wed, May 2, 2018 at 11:21 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason
>> <avarab@gmail.com> wrote:
>>> 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)