"Michael S. Tsirkin" <mst@xxxxxxxxxxxxxx> writes: > Quoting r. Michael S. Tsirkin <mst@xxxxxxxxxxxxxx>: >> So it seems git pull behaves differently depending on whether >> the origin pull line is first or not? > > Where do I find the code that decides whether to make an octopus > or many fetches? After "git fetch" that is called from "git pull", $GIT_DIR/FETCH_HEAD lists all the refs that were fetched, and each line has not-for-merge marker (or empty) in the second column (SHA1 <TAB> marker <TAB> description of what the remote ref is). The ones not marked with the not-for-merge marker are merged into the current head, so if you have more than one that lack not-for-merge marker, you end up with an octopus. The rule (the implementation might be broken but nobody other than you found the breakage so far) to mark not-for-merge is: - the refspecs are either given on the command line, or from shorthand file (.git/remotes/, or .git/branches/) but never from both at the same time; - when dealing with the refspecs from the command line all of them are for merge; - when dealing with the refspecs from the shorthand (.git/remotes), the one on the first "Pull: " line is for merge and everything else is not. The case statement in the loop you were touching in your patch we discussed earlier had four arms (+ref, .+ref, .ref, and ref). Pluses come from the original refspec given by the user, either from short-hand file or command line. Dot is prepended when reflist is prepared by get_remote_refs_for_fetch which in turn calls canon_refs_list_for_fetch (git-fetch sources git-parse-remote and these shell functions are defined there). - 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