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