cannot handle more than 29 refs

cannot handle more than 29 refs

[Jon Nelson]

I get this message whenever I use --tags with git-pull with certain 
repositories. The git repository is one, and so is my local repository. 
I googled and got nothing. I grepped the git archive and got only 
show-branch.c.  Can this be safely ignored? Is it a known shortcoming, 
or something else entirely?

--
Jon Nelson <jnelson-git@jamponi.net>

Re: cannot handle more than 29 refs

[Junio C Hamano]

Known shortcoming.

Re: cannot handle more than 29 refs

[Linus Torvalds]

On Tue, 27 Dec 2005, Jon Nelson wrote:
> 
> I get this message whenever I use --tags with git-pull with certain 
> repositories.

You shouldn't "pull" tags. You should just "fetch" them.

The error message comes from the fact that the pull is a "fetch + merge", 
and the merge logic tries to figure out what the common parent is with 
"git-show-branch". And the common parent finding is limited to 29 commits.

(Which is a very reasonable limit: the normal case is 2, and doing an 
octopus-merge with more than four or five parents is already insane. Much 
less 30 parents).

> The git repository is one, and so is my local repository. 
> I googled and got nothing. I grepped the git archive and got only 
> show-branch.c.  Can this be safely ignored? Is it a known shortcoming, 
> or something else entirely?

Well, it's a known shortcoming, but it really ends up being a sign of you 
doing the wrong thing and trying to merge all the tags together. The merge 
would almost certainly fail, btw, regardless of anything else.

Junio - I think we should make "git pull" refuse to merge more than one 
head. If somebody wants to do an octopus merge, they can use "git merge" 
instead. Hmm?

		Linus

Re: cannot handle more than 29 refs

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Junio - I think we should make "git pull" refuse to merge more than one 
> head. If somebody wants to do an octopus merge, they can use "git merge" 
> instead. Hmm?

That would lose the autogenerated merge message.  I can be
talked into making it 'core.expert = true' only, though.

More troubling is 'git pull --tags' should *not* even try to use
them for merging, so if it does that that needs to be fixed.

As I recall how I did (wanted to do) it, the default rule for
'pull' is:

 - if you have explicit head names on the command line (--tags
   does not count -- you are not stating name explicitly),
   all of them are merged into an octopus;

 - otherwise if you used remotes/ shorthand the head(s) on the
   first Pull: line;

 - otherwise HEAD;

And the code _is_ broken.  Here is a proposed fix.

-- >8 --
[PATCH] Do not mark tags fetched via --tags flag as mergeable

Otherwise "git pull --tags" would mistakenly try to merge all of
them, which is never what the user wants.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 767ca61..125bcea 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -192,7 +192,7 @@ then
 		sed -e '
 			/\^/d
 			s/^[^	]*	//
-			s/.*/&:&/')
+			s/.*/.&:&/')
 	if test "$#" -gt 1
 	then
 		# remote URL plus explicit refspecs; we need to merge them.

Re: cannot handle more than 29 refs

[Jon Nelson]

On Tue, 27 Dec 2005, Linus Torvalds wrote:

> 
> 
> On Tue, 27 Dec 2005, Jon Nelson wrote:
> > 
> > I get this message whenever I use --tags with git-pull with certain 
> > repositories.
> 
> You shouldn't "pull" tags. You should just "fetch" them.
> 
> The error message comes from the fact that the pull is a "fetch + merge", 
> and the merge logic tries to figure out what the common parent is with 
> "git-show-branch". And the common parent finding is limited to 29 commits.
> 
> (Which is a very reasonable limit: the normal case is 2, and doing an 
> octopus-merge with more than four or five parents is already insane. Much 
> less 30 parents).

^^^ Aha! I think I understand what's going on here - and you are right, 
I *don't* want to merge from all of those tags, I just want the content, 
so fetch is what I should be doing.  Thanks!

--
Jon Nelson <jnelson-git@jamponi.net>