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

Jay Soffian <jaysoffian@gmail.com> writes:

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.