Re: Running 'git pull' from an unnamed branch

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.04.06 08:42:16 +0100, Reece Dunn wrote:
> 2009/4/6 Junio C Hamano <gitster@pobox.com>:
> > Reece Dunn <msclrhd@googlemail.com> writes:
> >
> >> 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

This should not say "may", either you are or you are not on a detached
HEAD, and git can tell that, so it should not let the user have to
guess.

> 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>"

Checking out a named branch won't solve the "problem" on its own.
Consider this:

git checkout origin/foo
   *do stuff*

git pull
   *Oh! I need a named branch*

git checkout -b foo
git pull
   *Still fails*

Maybe:
You asked me to pull without telling me which branch you want to merge
with and as you have no branch checked out, I cannot look for any
defaults to use. Please name which branch you want to merge on the
command line and try again (e.g. 'git pull <repository> <refspec>'). See
git-pull(1) for details on the refspec.


That just adjusts the "you can set some defaults" part, replacing it
with a message telling that a detached HEAD cannot have any defaults.
Without implying anything about how the user might want to work, but
giving a hint that a branch can have defaults for "git pull".

Björn