Re: Running 'git pull' from an unnamed branch
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Apr 6, 2009, 10:03 UTC
- Message-ID
- <20090406100305.GD20356@atjola.homenet>
- In-Reply-To
- <3f4fd2640904060042m438a3a8en2d2746a6216b2b95@mail.gmail.com>
On 2009.04.06 08:42:16 +0100, Reece Dunn wrote:
Show 35 quoted lines
> 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 specifyThis 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