Jeff King [off-list ref] writes:

quoted

Meaning "git checkout origin" would look at origin/HEAD and find the
remote-tracking branch it points at, and uses that name?  I think
that does make quite a lot of sense.  You are correct to point out
that not just "git checkout origin/HEAD", but "git checkout origin",
currently detaches the HEAD at that commit, if you have origin/HEAD
pointing at one of the remote-tracking branches.

I'm not sure if it's a good idea to change "git checkout origin" here or
not. It already does something useful. I was mostly suggesting that the
other thing might _also_ be useful, but I'm not sure if it is wise to
change the current behavior.

Well, "git checkout origin/HEAD" would also do something useful,
which happens to be identical to "git checkout origin", to detach
HEAD at the commit.

I was thinking more like an explicit way to trigger the dwim-behavior,
like:

  # same as "git checkout foo" magic that creates "foo", but we
  # have said explicitly both that we expect to make the new branch, and
  # also that we expect it to come from origin.
  git checkout --make-local origin/foo

By default I think --guess (formerly known as --dwim) is enabled, so
"git checkout foo" is "git checkout --guess foo", which is making
local 'foo' out of the uniquely found remote-tracking branch.  This
new one is to reduce the "uniquely found" part from the magic and
let you be a bit more explicit, but not explicit enough to say "-t"
or "-b foo"?  I am not sure if this is all that useful.

If this were a slightly different proposal, I would see the
convenience value in it, though.  Currently what "--guess" does is:

      If the name 'foo' given does not exist as a local branch,
      and the name appears exactly once as a remote-tracking branch
      from some remote (i.e. 'refs/remotes/origin/foo' exists, but
      there is no other 'refs/remotes/*/foo'), create a local 'foo'
      that builds on that remote-tracking branch and check it out.

What would happen if we tweaked the existing "--guess" behaviour
slightly?

      "git checkout --guess origin/foo", even when there is a second
      remote 'publish' that also has a remote-tracking branch for
      its 'foo' (i.e. both 'refs/remotes/{origin,publish}/foo'
      exists), can be used to disambiguate among these remotes with
      'foo'.  You'd get local 'foo' that builds on 'foo' from the
      remote 'origin' and check it out.

  # similar, but because we are being explicit, we know it is reasonable
  # to dereference HEAD to find the actual branch name
  git checkout --make-local origin/HEAD

The user does not need "git symbolic-ref refs/remotes/origin/HEAD"
if such a feature were available.  "git checkout --some-option origin"
without having to say /HEAD may be a better UI, though.

And "checkout" being a Porcelain, and the DWIM feature that is
always on is subject to be improved for human use, I do not see why
that --some-option cannot be --guess.  If I want to get the current
behaviour, I can explicitly say "git checkout --detach origin"
anyway, no?

That seems orthogonal. Whether there is checkout magic or not, changing
what origin/HEAD points to would be disruptive to selecting it as a
tracking source, or doing diffs, or whatever. But that is why the
proposal in that series was to make the behavior configurable, and
default to "fill it in if missing" as the default, not "always update on
fetch".

Ah, I totally forgot that the favoured variant was "fill in if
missing, but don't move once it is set".  Yes, I think that is a
sensible default.

Thanks.