Michael Lukashov <michael.lukashov@xxxxxxxxx> writes:
> Steps to reproduce the bug:
>
> 1. Create repository and add more than one remote
> 2. Make sure current branch is tracking branch from the remote AND this remote
> is not last in the list of remotes
> 3. 'git pull --all' exits with error message:
>
> You asked to pull from the remote '--all', but did not specify
> a branch. Because this is not the default configured remote
> for your current branch, you must specify a branch on the command line.
>
> After 'git pull --all' you need to run 'git pull' to update current branch.
> This is annoying.
I started to rewrite the commit log message to present the backstory and
the assumptions existing code makes, _why_ things break, and then explain
what the proposed solution is and why it is the right fix to the problem
(by the way, presenting the log message this way helps you to think things
through). And I had to stop immediately after the description of _why_
things break:
"git fetch" learned "--all" option and it has become tempting for
users to say "git pull --all", even though it may not be absolutely
necessary to pull from many remotes that are not involved in the merge
about to happen to the current branch.
"git fetch --all" however clears the list of fetched branches every
time it contacts a different remote. Unless the current branch is
configured to merge with a branch from a remote that happens to be the
last in the list of remotes "fetch --all" contacts with, "git pull
--all" will not be able to find the branch it should be merging with.
Notice that presented this way, it becomes clear that it not a bug in
"pull --all" at all. "fetch --all" should be doing the clearing of
FETCH_HEAD at the very beginning (unless --append is given from the
command line, in which case it should just use FETCH_HEAD as-is), and then
run in the --append mode even when --append is not given.
So I think you identified a valid issue to address, but the patch is
solving it in a wrong way. The commit log message I started above would
be concluded with something like the following explanation of what the
proposed solution is and why it is the right fix:
Make "fetch --all" to clear FETCH_HEAD (unless --append is given) and
then append the list of branches fetched to it (even when --apend is
not given). That way, "pull --all" will be able to find the data for
the branch being merged in FETCH_HEAD no matter where the remote
appears in the list of remotes to be contacted by "git fetch".
and the patch would touch fetch, not pull.
--
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