Re: master^ is not a local branch -- huh?!?

Sverre Rabbelier [off-list ref] writes:

quoted

master^ is a commit (the first parent of master), not a branch (local
or otherwise).

Perhaps we should change the message to say "not a branch" if it's not
a reference to a remote branch? Or simply changing the text to "not a
(local) branch"?

I think "not a branch" is a good suggestion, whether the target of
checkout is "master^" or "origin/topic".

These days, you can say "git checkout topic" to automagically create a
local "topic" branch that forks from "origin/topic" remote tracking branch
when you have one, thanks to Dscho's UI improvement ideas (one less
reason you may end up on a detached HEAD state without wanting to).

Heya,

On Fri, Jan 29, 2010 at 21:48, Junio C Hamano [off-list ref] wrote:

I think "not a branch" is a good suggestion, whether the target of
checkout is "master^" or "origin/topic".

Mhhh, for added clarity, do we want to change it to "branch name"? Since ...

$ git grep "branch name" Documentation/ | wc -l
58

... suggests that we use that in other places as well?

-- 
Cheers,

Sverre Rabbelier

These days, you can say "git checkout topic" to automagically create
a local "topic" branch that forks from "origin/topic" remote tracking
branch when you have one, thanks to Dscho's UI improvement ideas. As
such it is more appropriate to say that the user is checking out
something that is not a branch name, rather than saying it is not a
'local branch'.

Signed-off-by: Sverre Rabbelier <redacted>
---

  Junio, I used part of your reply as the commit message, is that ok?

  Only change is s/local branch/branch name/.

 builtin-checkout.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..4b34314 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c

@@ -523,7 +523,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
 			   REF_NODEREF, DIE_ON_ERR);
 		if (!opts->quiet) {
 			if (old->path)
-				fprintf(stderr, "Note: moving to '%s' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n  git checkout -b <new_branch_name>\n", new->name);
+				fprintf(stderr, "Note: moving to '%s' which isn't a branch name\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n  git checkout -b <new_branch_name>\n", new->name);
 			describe_detached_head("HEAD is now at", new->commit);
 		}
 	}

-- 
1.6.6.rc1.56.gaea25.dirty

Signed-off-by: Jacob Helwig <redacted>
---

This should probably be squashed into Sverre Rabbelier's change, if this is
decided as the way to go.

 t/t7201-co.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 6442f71..b6e3216 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh

@@ -171,7 +171,7 @@ test_expect_success 'checkout to detach HEAD' '
 	git checkout -f renamer && git clean -f &&
 	git checkout renamer^ 2>messages &&
 	(cat >messages.expect <<EOF
-Note: moving to '\''renamer^'\'' which isn'\''t a local branch
+Note: moving to '\''renamer^'\'' which isn'\''t a branch name
 If you want to create a new branch from this checkout, you may do so
 (now or later) by using -b with the checkout command again. Example:
   git checkout -b <new_branch_name>

-- 
1.6.6.1

On Fri, 29 Jan 2010, Junio C Hamano wrote:

Sverre Rabbelier [off-list ref] writes:

quoted

quoted

master^ is a commit (the first parent of master), not a branch (local
or otherwise).

Perhaps we should change the message to say "not a branch" if it's not
a reference to a remote branch? Or simply changing the text to "not a
(local) branch"?

I think "not a branch" is a good suggestion, whether the target of
checkout is "master^" or "origin/topic".

These days, you can say "git checkout topic" to automagically create a
local "topic" branch that forks from "origin/topic" remote tracking branch
when you have one, thanks to Dscho's UI improvement ideas (one less
reason you may end up on a detached HEAD state without wanting to).

If this is the case then I'm really disappointed.

With all due respects, I don't share Dscho's sentiment about Git's 
alleged non user-friendliness.  And I always praised Git's ability to 
use a detached head to check out a remote branch, and never had any 
problem teaching this concept to people.  So the above is not a UI 
improvement at all to me.


Nicolas

Heya,

On Fri, Jan 29, 2010 at 22:19, Jacob Helwig [off-list ref] wrote:

This should probably be squashed into Sverre Rabbelier's change, if this is
decided as the way to go.

Ah, excellent point, apologies :(. I saw it show up when I grepped for
the message, not sure why I didn't do anything with that.

-- 
Cheers,

Sverre Rabbelier

Heya,

On Fri, Jan 29, 2010 at 22:20, Nicolas Pitre [off-list ref] wrote:

With all due respects, I don't share Dscho's sentiment about Git's
alleged non user-friendliness.  And I always praised Git's ability to
use a detached head to check out a remote branch, and never had any
problem teaching this concept to people.  So the above is not a UI
improvement at all to me.

I think 'git checkout origin/master^0' still works?

-- 
Cheers,

Sverre Rabbelier

On Fri, 29 Jan 2010, Sverre Rabbelier wrote:

Heya,

On Fri, Jan 29, 2010 at 22:20, Nicolas Pitre [off-list ref] wrote:

quoted

With all due respects, I don't share Dscho's sentiment about Git's
alleged non user-friendliness.  And I always praised Git's ability to
use a detached head to check out a remote branch, and never had any
problem teaching this concept to people.  So the above is not a UI
improvement at all to me.

I think 'git checkout origin/master^0' still works?

Then who was arguing about making Git more user friendly rather 
then less?


Nicolas

Heya,

On Fri, Jan 29, 2010 at 22:29, Nicolas Pitre [off-list ref] wrote:

Then who was arguing about making Git more user friendly rather
then less?

Using a detached head is a more advanced feature than wanting to
checkout a remote branch locally, creating a local tracking branch. As
such, 'git checkout origin/topic' now means the same as 'git checkout
-t origin/topic', and you can get the old behavior back by doing 'git
checkout origin/topic^0'. I don't see what the problem is, if you're
using a detached head you're an advanced enough git user that you can
remember that you can use '^0' to detach your head. It's not all that
uncommon to do 'git checkout HEAD^0' to detach your head to the
current branch, no?

-- 
Cheers,

Sverre Rabbelier

On Fri, 29 Jan 2010, Sverre Rabbelier wrote:

These days, you can say "git checkout topic" to automagically create
a local "topic" branch that forks from "origin/topic" remote tracking
branch when you have one, thanks to Dscho's UI improvement ideas. As
such it is more appropriate to say that the user is checking out
something that is not a branch name, rather than saying it is not a
'local branch'.

Signed-off-by: Sverre Rabbelier <redacted>

For the record, I'm providing a NAK.  First I don't agree with the UI 
"improvement" if there is no way to check out a remote branch without 
creating soon-to-be-stall local branches with the same name.

Next, the message can be made yet more clear and give the user more of a 
hint with what is going on.  Something like:

	"%s is not a local branch head: creating a detached HEAD\n"

plus the remaining clue lines.  This way people will have a much greater 
chance of understanding what state they're in, and a simple Google 
search for detached HEAD gives you the Git manual page with the needed 
info.


Nicolas

In article [off-list ref],
 Nicolas Pitre [off-list ref] wrote:

On Fri, 29 Jan 2010, Sverre Rabbelier wrote:

quoted

These days, you can say "git checkout topic" to automagically create
a local "topic" branch that forks from "origin/topic" remote tracking
branch when you have one, thanks to Dscho's UI improvement ideas. As
such it is more appropriate to say that the user is checking out
something that is not a branch name, rather than saying it is not a
'local branch'.

Signed-off-by: Sverre Rabbelier <redacted>

For the record, I'm providing a NAK.  First I don't agree with the UI 
"improvement" if there is no way to check out a remote branch without 
creating soon-to-be-stall local branches with the same name.

Next, the message can be made yet more clear and give the user more of a 
hint with what is going on.  Something like:

	"%s is not a local branch head: creating a detached HEAD\n"

plus the remaining clue lines.  This way people will have a much greater 
chance of understanding what state they're in, and a simple Google 
search for detached HEAD gives you the Git manual page with the needed 
info.

I agree that would be much better.

rg

On Fri, 29 Jan 2010, Sverre Rabbelier wrote:

Heya,

On Fri, Jan 29, 2010 at 22:29, Nicolas Pitre [off-list ref] wrote:

quoted

Then who was arguing about making Git more user friendly rather
then less?

Using a detached head is a more advanced feature than wanting to
checkout a remote branch locally, creating a local tracking branch. As
such, 'git checkout origin/topic' now means the same as 'git checkout
-t origin/topic', and you can get the old behavior back by doing 'git
checkout origin/topic^0'.

What purpose does this "feature" serve?  Making sure people remain 
stupid and get even more confused when the special dwimery doesn't work 
because they don't know the difference between a local branch and a 
remote tracking branch?

And now people will be left wondering why after a fetch they don't get 
the latest stuff when they do "git checkout topic" again.  Is this any 
better?

I don't see what the problem is, if you're
using a detached head you're an advanced enough git user that you can
remember that you can use '^0' to detach your head.

I don't agree with the assertion that a detached HEAD is for advanced 
users only.

It's not all that uncommon to do 'git checkout HEAD^0' to detach your 
head to the current branch, no?

Certainly way more uncommon than 'git checkout origin/foo', and way less 
intuitive.


Nicolas

Sverre Rabbelier wrote:

Heya,

On Fri, Jan 29, 2010 at 22:29, Nicolas Pitre [off-list ref] wrote:

quoted

Then who was arguing about making Git more user friendly rather
then less?

Using a detached head is a more advanced feature than wanting to
checkout a remote branch locally, creating a local tracking branch. As
such, 'git checkout origin/topic' now means the same as 'git checkout
-t origin/topic', and you can get the old behavior back by doing 'git
checkout origin/topic^0'. I don't see what the problem is, if you're
using a detached head you're an advanced enough git user that you can
remember that you can use '^0' to detach your head. It's not all that
uncommon to do 'git checkout HEAD^0' to detach your head to the
current branch, no?

[I'm still catching up on this thread]

What we call 'Detached head' is _the_ normal way ti use git for quite a 
number of users. And given the current UI, it's not really advanced.

Hi,

On Fri, 29 Jan 2010, Nicolas Pitre wrote:

With all due respects, I don't share Dscho's sentiment about Git's 
alleged non user-friendliness.

Of course you don't.  You are a Git oldtimer.  Probably you do not even 
have much exposure to complete programming newbies.

Well, guess what.  I have.  And guess what even more: they are the 
majority, not you and me.

Ciao,
Dscho

On Sat, 30 Jan 2010, Johannes Schindelin wrote:

Hi,

On Fri, 29 Jan 2010, Nicolas Pitre wrote:

quoted

With all due respects, I don't share Dscho's sentiment about Git's 
alleged non user-friendliness.

Of course you don't.  You are a Git oldtimer.  Probably you do not even 
have much exposure to complete programming newbies.

Welllll... That depends.

If you mean people who, despite a CS degree, are still unable to figure 
out if some loop exit condition should be > or >= except by testing the 
compiled code and see if a crash occurs, then yes I do feel the pain of 
being exposed to such people way too often for my taste.  And frankly I 
just don't care if those people can't grok the Git UI.

Git is meant to be a tool for people performing a minimum of development 
tasks.  If those people can't grasp the Git UI and concepts with little 
effort then they're either 1) uninterested or 2) incompetent.  For the 
uninterested people there are GUIs out there.  And don't get me started 
on the incompetent ones.

And for the rest of the world, such as my boss, there is gitweb.

Well, guess what.  I have.  And guess what even more: they are the 
majority, not you and me.

Did you ever got them to use P4?  I'm convinced that learning how to use 
P4 for a Git user is way more painful than a P4 user to learn Git.  
Similarly for Arch or many other alternatives.

HG looks easier?  Sure.  But it isn't exactly as flexible and powerful 
as Git is though.  You prefer a less powerful but simpler tool? OK just 
go with HG then -- I have no problem with that.  Even SVN might be just 
what you need.  But if you prefer the power of Git then there is a price 
to pay for it.  Making Git simpler would inevitably reduces its power.

I hope newbies won't stay newbies all their life.  If the majority of 
all the people are newbies then no need to wonder why there is so much 
crap being produced by the computing industry then.  Learning isn't only 
a nasty thing that they force you to do at school and which you get over 
with once you escape from there.

Incidentally we've been getting more positive feedback than negative 
ones about Git from newbies on this list lately.  That might be because 
our UI, although still not perfect, improved quite a bit, and most 
probably because the documentation surrounding Git has improved 
tremendously too.


Nicolas

On Fri, Jan 29, 2010 at 04:51:18PM -0500, Nicolas Pitre wrote:

quoted

Using a detached head is a more advanced feature than wanting to
checkout a remote branch locally, creating a local tracking branch. As
such, 'git checkout origin/topic' now means the same as 'git checkout
-t origin/topic', and you can get the old behavior back by doing 'git
checkout origin/topic^0'.

What purpose does this "feature" serve?  Making sure people remain 
stupid and get even more confused when the special dwimery doesn't work 
because they don't know the difference between a local branch and a 
remote tracking branch?

And now people will be left wondering why after a fetch they don't get 
the latest stuff when they do "git checkout topic" again.  Is this any 
better?

I am entering the discussion a bit late, and things have moved on from
this point, but I wanted to mention that I have in the past made the
same argument that you have in your second paragraph (that you leave
users _more_ confused after a fetch), but somebody (I think Jay) managed
to convince me otherwise.

The saving feature is that we now print out the symmetric difference
information between a branch and its upstream during checkout. So the
user experience looks like:

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

  ... time passes ...

  $ git fetch
  ...
     9f137a4..22ac6a6  topic      -> origin/topic

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

So I think it is not quite as bad as at least I had originally thought.
There are still a few rough edges, though:

  1. If I stay on the 'topic' branch and run "git fetch", then I don't
     see the checkout message. If I don't understand that a local branch
     has been created, I might expect the new changes to be present. But
     they're not. If I do a pull instead, it does "just work", even if I
     am clueless about the local branch.

     I wonder if a "fetch" which updates the upstream branch of the
     current HEAD should print something like the "Your branch is
     behind..." message.

  2. If I am clueless that the local branch exists, I can see that there
     are new changes that I can "fast forward". But if I am clueless
     about local branches, do I know that means I need to run "git merge
     origin/topic"?  However, I can't think of an improved message that
     would make the situation clear without adding a bunch of annoying
     text.

-Peff

In article [off-list ref],
 Jeff King [off-list ref] wrote:

     I can't think of an improved message that
     would make the situation clear without adding a bunch of annoying
     text.

In situations like that a pointer to the docs, or a keyword to search on 
is often sufficient.

rg