I found this message when trying to see if someone had already suggested
something along those lines.
In fact I would be even more restrictive: what I wanted to propose was
to only automatically setup the merge on implicit remote tracking
branches, that is:
git switch foo
if there is no such branch locally will look for the corresponding
branch in the remotes, and will create a matching local one. In that
case it makes a lot of sense to create a remote-tracking branch: when
implicitly checking out a remote branch, it's likely the goal is to
track it.
The issue is that
git switch -c bar foo
will do the same, despite explicitely creating a differently named
branch, which is probably some sort of feature which needs to be
remote-ed somewhere else. If this issue is not caught immediately it is
possible to push directly upstream by mistake.
Upon reading the documentation of `git switch` I actually believed this
would behave correctly given `autoSetupMerge=false`:
--guess, --no-guess
If <branch> is not found but there does exist a tracking branch
in exactly one remote (call it <remote>) with
a matching name, treat as equivalent to
$ git switch -c <branch> --track <remote>/<branch>
Because `--guess` is the default for the `git switch <name>` form, this
description made me believe the tracking would be forced.
Sadly it is not so, setting `autoSetupMerge=false` will also disable
automatic remote-tracking on guessed branch.
As far as I'm concerned, `git switch` actually behaving as documented
would resolve the entire issue (especially if it were possible to
disable `git checkout` somehow, such that I would have to force muscle
memory).
This is made more annoying because
git switch -t foo
*does not work*, frustratingly (if as documented, this time) `-t`
implies `-c`. So it's not even possible to remember to type `git switch
-t remotebranch` and then live happily with `autoSetupMerge=false`. This
makes `autoSetupMerge=false` a lot more frustrating that necessary.
