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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2009, 21:59 UTC
Message-ID: <7vaazvt0pk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

> So in my opinion, we should DWIM "git checkout $X" to mean "git checkout 
> -b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and 
> no other refs/remotes/$OTHER/$X.
>
> Likewise "git checkout $REMOTE/$X".
>
> But, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X, 
> and the user says "git checkout origin/$X", we should tell the user that 
> there are the options to checkout $X and origin/$X^0 (the latter only if 
> the user really intended to detach her HEAD), but not try to DWIM 
> anything.

I am somewhat unhappy with that kind of inconsistent DWIMery.

Naively I would agree that it would be nice if "git checkout origin/next" (or "next" when no other remotes/*/next exists) were DWIMmed as "git checkout -t -b next origin/next". But the way we _define_ that particular DWIMmery and the way it appears to an uninitiated would be different.

We define this DWIMmery as s|^(.*)/([^/]*)$|-t -b $2 $1/$2|; iow, when the user types "origin/next" and other coniditions hold, we pretend as if the user typed "-b next origin/next". But it would give an incorrect impression to an end user "Ah, when my upstream project has next branch, I can check it out with origin/next (or next)." But when the user wants to work further on 'next' by running "git checkout origin/next" the next day, we say "Uh oh, that is ambiguous and we won't DWIM," which is technically and implementation wise correct, but breaks the misconception the user formed with your earlier DWIMmery. I suspect that the user will be better off if we do not give a wrong impression in the first place. If any DWIMmery gave a conception different from the following four points, that DWIMmery is actively hurting the users:

 * You clone and get copies of where the other end has its branches;

 * You do all your work on your local branches;

 * You may incorporate what the other end further did by merging from the
   tracking branch from it;

 * You update the other end by pushing what you did on your local branches.

Now, the conclusion of the above embodied in the _current_ UI is:

 * To start your branch to build on what the other end did, you fork your
   local branch at the commit the other end left off, and make sure it builds
   on that tracking branch, with

        git checkout -t -b next origin/next

 * Since "-t -b $2 $1/$2" often appears as a pattern, you can say "-t $1/$2"
   and we DWIM as if you said "-t -b $2 $1/$2".

I do not think loosening the DWIMmery so that "$1/$2" is DWIMmed to the above would help users. If the current DWIM is not helping the users understand the first four points and instead encouraging an incorrect picture of how the world works, the new DWIMmery would be just as bad, if not worse.

> IMHO it is obvious that Hannes' suggestion to fast-forward $X and check it 
> out in said scenario has some benefits in certain situations, but dramatic 
> downsides in others.

Yes.

Show 7 quoted lines

> But I need to drive some very important point home in this thread: 1.7.0 
> was announced to break some old-time habits in favor of a better 
> user-interface.  We _need_ to use this opportunity fully.
>
> Even if that means that a few fingers have to be retrained.  Because 
> retraining a few for the benefit of an easier time with the many others 
> is Just Worth It.

Absolutely. My point is that this particular DWIMmery would _NOT_ be a better user interface. Not for 1.7.0, not for any other release. It would not help the users to form a clear world model git offers and that actively hurts them.