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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 4, 2018, 07:14 UTC
Message-ID: <CAPig+cSRBBzXDWMJd5k=ZGOt_ayATWB6fZQrcMqJkP8ja4Tq+g@mail.gmail.com>
In-Reply-To: <87y3h1ykwn.fsf@evledraar.gmail.com>

On Wed, May 2, 2018 at 2:25 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 17 quoted lines

> On Wed, May 02 2018, Eric Sunshine wrote:
>> 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).

A reasonable concern.

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

Considering that git-worktree runs the post-checkout hook, it seems pretty safe to say that it does something checkout-like.

Personally, I find "defaultRemote" easier to understand than "implicitRemote", but I suppose I can see your reasoning for choosing "implicit". Whereas "default" is something to "fall back upon" when something is missing, "implicit" suggests what to choose when a something has not been specified explicitly.

Show 21 quoted lines

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

Yes, you misunderstood it.

The setting up of a remote-tracking branch is DWIM'd as of 4e85333197 ("worktree: make add <path> <branch> dwim", 2017-11-26); it doesn't require an explicit option to enable it (though tracking can be disabled via --no-track). The "guess-remote" feature does something entirely different; it was added to avoid backward compatibility problems.

In long-form:

    git worktree add <path> <branch>

adds a new worktree at <path> and checks out <branch>. As originally implemented, shortened:

    git worktree add <path>

does one type of DWIM, as a convenience, and pretends that the user actually typed:

    branch=$(basename <path>)
    git branch $branch HEAD
    git workree add <path> $branch

which creates a new branch and then checks it out in the new worktree as usual. The "guess remote" feature which Thomas added augments that by adding a DWIM which checks if $(basename <path>) names a remote-tracking branch, in which case, it becomes shorthand for (something like):

    branch=$(basename <path>)
    if remote-tracking branch named $branch exists:
        git branch --track $branch $guessedRemote/$branch
    else:
        git branch $branch HEAD
    fi
    git worktree add <path> $branch

In retrospect, this DWIM-checking for a like-named remote-tracking branch should have been implemented from the start in git-worktree since it mirrors how "git checkout <branch>" will DWIM remote-tracking <remote>/<branch>. However, such DWIM'ing was overlooked and git-worktree existed long enough without it that, due to backward compatibility concerns, the new DWIM'ing got hidden behind a switch, hence --guess-remote ("worktree.guessRemote") to enable it.

Unrelated: Thomas added another DWIM, which we just finalized a few
days ago, which extends the shorthand "git worktree add <path>" to
first check if a local branch named $(basename <path>) already exists
and merely check that out into the new worktree rather than trying to
create a new branch of that name (which is another obvious DWIM missed
during initial implementation). In other words:

    branch=$(basename <path>)
    if local branch named $branch does _not_ exist:
        if remote-tracking branch named $branch exists:
            git branch --track $branch $guessedRemote/$branch
        else:
            git branch $branch HEAD
        fi
    fi
    git worktree add <path> $branch