Re: RFC: git pull <remote> making an octopus?

[Junio C Hamano <junkio@cox.net>]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

> Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>:
>> 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).