2009/4/6 Björn Steinbrink <B.Steinbrink@xxxxxx>:
> On 2009.04.06 08:42:16 +0100, Reece Dunn wrote:
>> 2009/4/6 Junio C Hamano <gitster@xxxxxxxxx>:
>> > Reece Dunn <msclrhd@xxxxxxxxxxxxxx> 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.
Sounds reasonable. I'll update the patch and resubmit later on today.
> 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
- Reece
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html