Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html