Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> This doesn't help with the original problem, which was that a user
> attempted to checkout refs/remotes/origin/<name> by just saying 'git
> checkout <name>' which I happen to think should work. A lot of what I
> keep hearing in this thread seems to be in the vein of the perfect
> being the enemy of the good.

I do not think there is "perfect" nor "good" anywhere in this.  It is just
the proposals were either not well thought out, were not presented well,
or were misunderstood, or a bit of all.

When you do not have local "frotz" branch, and do have cloned/fetched from
the origin that has "frotz" branch, I am actually Ok with this

    $ git checkout frotz [--]

to do an equivalent of:

    $ git checkout -t -b frotz origin/frotz

I do not have problem with this _particular_ DWIMmery.  It will not break
people's expectations, other than "asking to check out non-existing ref
should fail".  That expectation might be logical, but I do not think it is
useful.

Another reason I won't have problem with this one is that perhaps after
creating a few more commits, the next day when the user does the same

    $ git checkout frotz

what will be shown is the _local_ frotz branch.  Nowhere in this sequence
there is any room to mistake that you somehow checked out a branch owned
by somebody else (namely, origin).  You started by auto-creating your
local branch, worked on it, and checked it out again the next day.  In
other words, this is really about a shorthand to create a new local branch
called "frotz" when the commit that the branch should start from is
clearly unambiguous.

I have trouble with yours, on the other hand, which is to make

    $ git checkout origin/frotz
    $ git checkout v1.5.5

into

    $ git checkout -b frotz-47 origin/frotz
    $ git checkout -b v1.5.5-47 v1.5.5

(replace -47 with whatever random string you would come up with to make it
unique), as it _will_ break people's expectations, and the expected
behaviour to detach without polluting the local branch namespace for
the purpose of sightseeing happens to be a useful one.

I also have issues with turning

    $ git checkout origin/frotz

into

    $ git checkout -b frotz origin/frotz

only when frotz does not exist locally.  This will cause the "next day"
problem, and also by naming the remote tracking branch, gives a wrong
impression that this is about a remote branch.  It should not be.

Perhaps without touching the "detached" case at all, if we limit the scope
of the change that comes out of this discussion to only one case, it might
result in a good trouble-free enhancement [*1*].

The new rule would be:

    "git checkout $name", when all of the following holds:

    - $name is a good name for a local branch (i.e. check-ref-format is
      happy);

    - No local branch of that name exists;

    - There is exactly one remote $remote that has $name branch; and

    - $name itself is not a good commit name (i.e. get_sha1() barfs)

    is a request to create a local branch $name, and the branch tracks the
    remote tracking branch found in the third condition [*2*].

The important point here is that this exception is _not_ about remote
tracking branch but is about a rule to allow omitting -b to create and
checkout a local branch when the user's intent is clear that (1) he wants
to create a new one named $name, and (2) he wants to create it starting at
the commit $remote/$name.

Such a change feels quite safe and I wouldn't be opposed to it.

We _could_ discuss extending the $name in the above rule to other kinds
(tags and even arbitrary committish that may not even have a direct ref
pointing at it), but I think they are much more problematic.

[Footnote]

*1* Yes, I know I won't try to come with a strawman.

*2* The fourth condition is to avoid taking "origin/frotz" when "origin"
remote has "frotz" branch _and_ "other" remote has "origin/frotz" branch.

The remote chosen by the third condition would be "other" (because
"origin" remote only has "frotz", and not "origin/frotz", the name is
unique in the sense of the third condition).  The fourth condition
prevents this from happening, and forbids an explicit request to detach
HEAD at one point (i.e. "origin/frotz") from triggering.