Hi, On Fri, May 8, 2015 at 1:38 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Paul Tan <pyokagan@xxxxxxxxx> writes: > >> error_on_no_merge_candidates() does not consider the case where "$#" >> includes command-line flags that are passed to git-fetch. >> >> As such, when the current branch has no configured upstream, and there >> are no merge candidates because of that, git-pull --all erroneously reports >> that we are pulling from "--all", as it believes that the first argument >> is the remote name. > > Interesting. > > I do not think "pull [origin] --all" makes much sense for the same > reason why we error out when you say "pull [origin] --tag", so I am > not sure "There is no tracking information" is the right diag we > would want to give the user, but I agree that "--all" is not a > remote name. > > Does the same comment as 11/12 applies to this as well? This is actually only just one symptom of the problem of git-pull assuming in many places that "$1" is the remote. There are other possible ones, such as git pull --rebase failing silently at finding the upstream branch to pass to git-rebase when git-fetch flags are passed as well (see git-pull.sh:253), though crafting a test case for that would be a bit more involved. Maybe if I have extra time to look into it. Then there is the problem where command line flag parsing stops when an unidentified flag is encountered, assuming that it is for git-fetch. E.g. git-pull --all --dry-run will pass --dry-run to git-fetch, but will still run git-merge. Now, I haven't written this up as a test case yet because I haven't the time yet, and it could be argued that this is expected behavior, as the git-pull docs say that options meant for git-fetch must come after git-pull. However, this is ultimately really confusing for end-users, so I propose that we just drop the distinction between git-pull's flags and git-fetch's flags, and just parse them all at git-pull. This can be done with the current git-pull.sh, but would be easier with the superior C parse-options API. Thanks, Paul -- 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