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