On Thu, May 3, 2018 at 3:18 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > Introduce a checkout.implicitRemote setting which can be used to > designate a remote to prefer (via checkout.implicitRemote=origin) when > running e.g. "git checkout master" to mean origin/master, even though > there's other remotes that have the "master" branch. > > I want this because it's very handy to use this workflow to checkout a > repository and create a topic branch, then get back to a "master" as > retrieved from upstream: > > ( > rm -rf /tmp/tbdiff && > git clone git@xxxxxxxxxx:trast/tbdiff.git && > cd tbdiff && > git branch -m topic && > git checkout master > ) > > That will output: > > Branch 'master' set up to track remote branch 'master' from 'origin'. > Switched to a new branch 'master' > > But as soon as a new remote is added (e.g. just to inspect something > from someone else) the DWIMery goes away: > > ( > rm -rf /tmp/tbdiff && > git clone git@xxxxxxxxxx:trast/tbdiff.git && > cd tbdiff && > git branch -m topic && > git remote add avar git@xxxxxxxxxx:avar/tbdiff.git && > git fetch avar && > git checkout master > ) > > Will output: > > error: pathspec 'master' did not match any file(s) known to git. > > The new checkout.implicitRemote config allows me to say that whenever > that ambiguity comes up I'd like to prefer "origin", and it'll still > work as though the only remote I had was "origin". > > I considered splitting this into checkout.implicitRemote and > worktree.implicitRemote, but it's probably less confusing to break our > own rules that anything shared between config should live in core.* > than have two config settings, and I couldn't come up with a short > name under core.* that made sense (core.implicitRemoteForCheckout?). I wonder if it's difficult to add a dwim hook that allows us to replace the entire dwim logic with a hook? Doing this "preferring origin" in a shell script should be easy and it lets us play more with tweaking dwim logic. (Yeah sorry I'm getting off topic again) -- Duy
