Re: Running 'git pull' from an unnamed branch

2009/4/6 Junio C Hamano [off-list ref]:

Reece Dunn [off-list ref] writes:

quoted

diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..00a72dd 100755
--- a/git-pull.sh
+++ b/git-pull.sh

@@ -97,6 +97,10 @@ error_on_no_merge_candidates () {

      echo "try again (e.g. 'git pull <repository> <refspec>')."
      echo "See git-pull(1) for details on the refspec."
      echo
+     echo "You may not be on a branch. In this case, you need to move"
+     echo "onto the branch you want to pull to (usually master):"
+     echo "    git checkout <branch>"
+     echo

I do not think that is necessarily what the user wanted to hear.  Often I
create trial merges on a detached HEAD when I hear a pull-request from
others (I have a few work trees that share the repository with my primary
working area, made with contrib/workdir/git-new-workdir script, and their
HEAD are typically detached at the tip of the master), and in such a use
case, the first line of the instruction in the context in your patch is
the right thing to give.  I do not want to have the resulting trial merge
anywhere on my real branches, and do not want to be told to switch to any
of them.

We really should teach people, especially the new ones early on, that "git
push" and "git pull" are meant to be told where-to/from and what, and how
to drive these commands with explicit arguments, before letting them rely
on the default configuration blindly without understanding the underlying
concepts.

Ok, so how about something like:

"You may not be on a branch. Because of this, you need to specify
where you are pulling from and to. See git-pull(1) for how to do this.
Alternatively, you can move to a named branch using:
    git checkout <branch>"

The automation given by the configuration variables is certainly nice, and
the default created by "clone", "remote add" and "checkout -b" (with its
implicit "track") may make them simpler to operate for every day life, but
there is a limit.  Working on a detached HEAD is an ultimate free-form
hacking, and you do not even necessarily _want_ to have a "while my HEAD
is detached, please always do this" default configured.

How about the above wording? I have kept the moving to a named branch,
but have made it optional and secondary to using git pull with
arguments. This supports the workflow you and others have described,
while retaining the hint for when you don't want to work on a detached
HEAD - for example, after running bisect - without saying that the
latter is required.

- Reece