RFC: git pull <remote> making an octopus?

RFC: git pull <remote> making an octopus?

[Michael S. Tsirkin]

Hi!
If I do

$git pull origin

where origin is a file in .git/remotes/origin with multiple Pull: lines,
then I seem to get an octopus merge. I would expect it to behave
in the same way as git pull without parameters.
Is this a bug or a feature?

My git pull page says:
              While
              git-pull run without  any  explicit  <refspec>  parameter  takes
              default  <refspec>s  from  Pull: lines, it merges only the first
              <refspec> found into the current branch, after fetching all  the
              remote  refs. This is because making an Octopus from remote refs
              is rarely done, while keeping track of multiple remote heads  in
              one-go by fetching more than one is often useful.

So, the same logic seems to apply to anything under .git/remotes.
Right?

-- 
MST

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

[Junio C Hamano]

"Michael S. Tsirkin" <mst@mellanox.co.il> 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?

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

[Michael S. Tsirkin]

Quoting r. Junio C Hamano <junkio@cox.net>:
> 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

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

[Michael S. Tsirkin]

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?

-- 
MST

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

[Junio C Hamano]

"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).

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

[Alex Riesen]

On 8/14/06, Junio C Hamano <junkio@cox.net> 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?

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

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> On 8/14/06, Junio C Hamano <junkio@cox.net> 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?

You should be able to make octopus -- I designed it that way on
purpose, but I haven't used that (mis)-"feature" for quite a
while, so it might have got broken along the way ;-).

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

[Junio C Hamano]

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

> Quoting r. Junio C Hamano <junkio@cox.net>:
>> 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.

Doesn't reproduce for me and I am getting worried.
Has anybody else seen this?

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

[Alex Riesen]

On 8/17/06, Junio C Hamano <junkio@cox.net> wrote:
> >> 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.
>
> Doesn't reproduce for me and I am getting worried.
> Has anybody else seen this?
>

I haven't. Michael, could you retry with "GIT_TRACE=1 sh -x -v git-pull" ?
I suspect invisible (like \r) character in your remotes. Missing last \n could
be interesting too.

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

[Michael S. Tsirkin]

Quoting r. Junio C Hamano <junkio@cox.net>:
> > No, I just reproduced this on plain 1.4.2.
> 
> Doesn't reproduce for me and I am getting worried.

No, that was my mistake, sorry about not clarifying that.

Basically what confused me was the following text in get-fetch manpage:

	While git-pull  run  without  any  explicit <refspec> parameter takes
	default <refspec>s from Pull: lines, it merges only  the  first
	<refspec> found into the current branch, after fetching all the remote
	refs.

And this actually applied to remotes in $GITDIR/remotes and not just
when git-pull is run without any parameters.

-- 
MST