"Michael S. Tsirkin" [off-list ref] writes:
$ git pull origin
where origin is a file in .git/remotes/origin with multiple Pull: lines,
then I seem to get an octopus merge.
You shouldn't.
I have four Pull: lines like these for .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git/
Pull: master:refs/tags/ko-master
Pull: next:refs/tags/ko-next
Pull: +pu:refs/tags/ko-pu
Pull: maint:refs/tags/ko-maint
Push: heads/master
Push: heads/next
Push: +heads/pu
Push: heads/maint
and "git pull ko" leaves this in .git/FETCH_HEAD:
460c... branch 'master' of .kernel.org:/pub/scm/git/git
767f... not-for-merge branch 'next' of .kernel.org:/pub/scm/git/git
9bd4... not-for-merge branch 'pu' of .kernel.org:/pub/scm/git/git
9a1a... not-for-merge branch 'maint' of .kernel.org:/pub/scm/git/git
The latter three are not merged into the current branch with the
above pull command.
Are you by any chance running a version of git that has some
unofficial patches that affect the generation of not-for-merge
markers?
Quoting r. Junio C Hamano [off-list ref]:
Are you by any chance running a version of git that has some
unofficial patches that affect the generation of not-for-merge
markers?
No, I just reproduced this on plain 1.4.2.
My .git/remotes/origin has:
URL: /mswg/git/infiniband/.git
Pull: refs/heads/ofed_1_1:refs/heads/ofed_1_1
Pull: refs/heads/cma_branch:refs/heads/cma_branch
Pull: refs/heads/linus_master:refs/heads/linus_master
Pull: refs/heads/master:refs/heads/master
Pull: refs/heads/mst_sdp:refs/heads/mst_sdp
Pull: refs/heads/ofed_addons:refs/heads/origin
Moving the last line
Pull: refs/heads/ofed_addons:refs/heads/origin
to be the first, like this
Pull: refs/heads/ofed_addons:refs/heads/origin
Pull: refs/heads/ofed_1_1:refs/heads/ofed_1_1
Pull: refs/heads/cma_branch:refs/heads/cma_branch
Pull: refs/heads/linus_master:refs/heads/linus_master
Pull: refs/heads/master:refs/heads/master
Pull: refs/heads/mst_sdp:refs/heads/mst_sdp
fixes the issue.
So it seems git pull behaves differently depending on whether
the origin pull line is first or not?
--
MST
Quoting r. Michael S. Tsirkin [off-list ref]:
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?
--
MST
"Michael S. Tsirkin" [off-list ref] writes:
Quoting r. Michael S. Tsirkin [off-list ref]:
quoted
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).
On 8/14/06, Junio C Hamano [off-list ref] wrote:
- 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.
What happens if you have _many_ refspecs in a "Pull:"-line?