Re: DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"

Clemens Buchacher [off-list ref] writes:

The suggestion above would be perfect. It is an easy and obvious
solution, and the user is even educated about their mistake.

Of course, having been educated as to what's going on, the user would
then be annoyed that they had to type all those boilerplate args when
git clearly knew what they wanted to do... and that would be the case
every time from then on...

I think this DWIM is actually pretty convenient, and very often does
reflect what the user intuitively is trying to do when giving such args.

Given that git _does_ tell you what it's doing, and that it's easy
enough to delete the new branch if it wasn't really wanted, it seems
pretty harmless as well.  A campaign to delete this feature seems kind
of silly...

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

On Mon, Jun 07, 2010 at 03:41:58PM +0900, Miles Bader wrote:

Clemens Buchacher [off-list ref] writes:

quoted

The suggestion above would be perfect. It is an easy and obvious
solution, and the user is even educated about their mistake.

Of course, having been educated as to what's going on, the user would
then be annoyed that they had to type all those boilerplate args when
git clearly knew what they wanted to do... and that would be the case
every time from then on...

Why should the user make the same mistake over and over again?

I think this DWIM is actually pretty convenient, and very often does
reflect what the user intuitively is trying to do when giving such args.

Given that git _does_ tell you what it's doing, and that it's easy
enough to delete the new branch if it wasn't really wanted, it seems
pretty harmless as well.  A campaign to delete this feature seems kind
of silly...

It may be harmless to users who know what's going on. I can
certainly deal with this feature, whether it's there or not.

But this is supposedly a feature which helps users who type "git
checkout <branch>" by mistake, when they really wanted to do "git
checkout -t <remote>/<branch>". I am certain that most new users
who make this mistake will not understand what's going on, even if
they read the output.

I believe that it's because of things like this that many users
still consider git to be complicated and hard to use. That's what
really bothers me.

And it makes me sad that you think it silly to even talk about it.
Even if the feature does not end up getting removed I still hope
that we will exercise more caution in the future and try to solve
the real problem--which appears to be remote branch
handling--rather than introducing more strange behavior.

Regards,
Clemens

On Tue, Jun 8, 2010 at 3:54 AM, Clemens Buchacher [off-list ref] wrote:

quoted

then be annoyed that they had to type all those boilerplate args when
git clearly knew what they wanted to do... and that would be the case
every time from then on...

Why should the user make the same mistake over and over again?

What I mean is that every time thereafter that they want that
functionality (making a remote branch local), they'll have to type the
"long form".

And it makes me sad that you think it silly to even talk about it.

I don't think it's silly to note your concern, I think it's silly to
put a fair amount of effort into a campaign for its removal, which is
what you are doing.  If new points can be made, fair enough, but so
far it seems mainly a lot of back and forth stating the same things
over and over.

I believe that it's because of things like this that many users
still consider git to be complicated and hard to use. That's what
really bothers me.

Why do you think that?  I mean, you could be right, but it's certainly
conceivable that this feature causes users to consider git _simpler_
to use, because it lets them think about local branches only.

-Miles

-- 
Do not taunt Happy Fun Ball.

On Tue, Jun 08, 2010 at 09:25:07AM +0900, Miles Bader wrote:

quoted

And it makes me sad that you think it silly to even talk about it.

I don't think it's silly to note your concern, I think it's silly to
put a fair amount of effort into a campaign for its removal, which is
what you are doing.  If new points can be made, fair enough, but so
far it seems mainly a lot of back and forth stating the same things
over and over.

Since I started this, I feel responsible for responding to people's
comments. I do not think I am doing anything wrong. So please
forgive me for responding to you as well, even if you think it
silly of me.

quoted

I believe that it's because of things like this that many users
still consider git to be complicated and hard to use. That's what
really bothers me.

Why do you think that?  I mean, you could be right, but it's certainly
conceivable that this feature causes users to consider git _simpler_
to use, because it lets them think about local branches only.

Thinking about local branches only is wrong.

Let's assume the user "just wants to check out branch X." Such a
use case has been mentioned previously in this thread. So they say
"git checkout X", and voila, they get what they wanted.

It did what they meant it to do. Everybody is happy. But not for
long.

Because the next time they "just want to check out branch X," they
will remember, it's time for "git checkout X." But what's this?
This is not what they wanted. It does not have the latest changes
on branch X! Didn't they do the same thing they did last time?

No they did not, because last time they _created a branch_.
Eventually, if they are lucky, they will learn in #git that they
were supposed to "git merge <remote>/X." And they will think "WTF?
Why do I have to _merge_? And what's this business about remotes?
Why is git is so complicated?"

So all we did was delay the user's confusion, and make it worse,
because now the mind model of "local branches only" they have
developed, is broken.

Git uses slightly different semantics than other VCSs, especially
when it comes to branches. And that often causes users to become
confused. But I happen to think that git's branch model is
superior, and easy to understand once you unlearn what you know
from other VCSs.

But if we try to hide that fact and imitate other VCSs on the
surface, that will only make it harder to learn.

Regards,
Clemens

On 8 June 2010 09:29, Clemens Buchacher [off-list ref] wrote:

No they did not, because last time they _created a branch_.
Eventually, if they are lucky, they will learn in #git that they
were supposed to "git merge <remote>/X." And they will think "WTF?
Why do I have to _merge_? And what's this business about remotes?
Why is git is so complicated?"

I'm confused. Wont they actually be told:

  git checkout $foo
  git pull
  git push

Why would they need to do a git merge $remote/X?

The only reason I can think of is that they are doing cross branch
merges, but then they are by default beyond the novice user and can be
expected to know various things, and to have read the docs.

Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

On Tue, Jun 08, 2010 at 09:29:58AM +0200, Clemens Buchacher wrote:

Let's assume the user "just wants to check out branch X." Such a
use case has been mentioned previously in this thread. So they say
"git checkout X", and voila, they get what they wanted.

It did what they meant it to do. Everybody is happy. But not for
long.

Because the next time they "just want to check out branch X," they
will remember, it's time for "git checkout X." But what's this?
This is not what they wanted. It does not have the latest changes
on branch X! Didn't they do the same thing they did last time?

No they did not, because last time they _created a branch_.
Eventually, if they are lucky, they will learn in #git that they
were supposed to "git merge <remote>/X." And they will think "WTF?
Why do I have to _merge_? And what's this business about remotes?
Why is git is so complicated?"

FWIW, I made this same complaint at the GitTogether, and the response I
got is that git does help the user along through the second "checkout".
You get something like:

  $ git checkout foo
  Branch private set up to track remote branch foo from origin.
  Switched to a new branch 'foo'

  ... time passes ...

  $ git checkout foo
  Switched to branch 'foo'
  Your branch is behind 'origin/foo' by 5 commits, and can be fast-forwarded.

Now you can certainly argue that a clueless user won't know what to do
with those messages, but it is not entirely true that git leaves them
without any advice. Perhaps we could lessen the "wtf" moment in your
example above by making that advice better.

-Peff

On Tue, Jun 8, 2010 at 4:29 PM, Clemens Buchacher [off-list ref] wrote:

Eventually, if they are lucky, they will learn in #git that they
were supposed to "git merge <remote>/X."

They don't have to do that, they just have to do "git pull".  This
concept -- that to get the latest changes, one pulls -- is something
people learn very early.

So, in fact it seems quite natural -- you switch to a local branch
with "git co branch", and then if git tells you it's not up-to-date,
you "git pull".  All nice and smooth and simple and standard.  The
DWIM simply makes the first time less clumsy, and while everybody
benefits, beginners probably benefit a bit more.

-Miles

-- 
Do not taunt Happy Fun Ball.

On Tue, Jun 08, 2010 at 03:52:42AM -0400, Jeff King wrote:

  $ git checkout foo
  Branch private set up to track remote branch foo from origin.
  Switched to a new branch 'foo'

  ... time passes ...

  $ git checkout foo
  Switched to branch 'foo'
  Your branch is behind 'origin/foo' by 5 commits, and can be fast-forwarded.

I see. That really is somewhat reassuring. I still do not like it,
but considering the fact that I could not come up with a scenario
worse than that, I suppose the feature is not as bad as I made it
out to be.

Thanks all for discussing it with me anyways.

Regards,
Clemens