On Wed, May 2, 2018 at 2:25 PM, Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> 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.
>> 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
