# cannot handle more than 29 refs 5 messages from 2005-12-27 to 2005-12-27. Participants: Jon Nelson, Junio C Hamano, Linus Torvalds. Thread: https://gitlist.dev/t/2938 ## Jon Nelson, 2005-12-27 14:43 Subject: cannot handle more than 29 refs Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0512270840410.6812%40gheavc.wnzcbav.cig ``` 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 ``` ## Junio C Hamano, 2005-12-27 16:48 Subject: Re: cannot handle more than 29 refs Message-ID: <7vhd8ubi58.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhd8ubi58.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Known shortcoming. ``` ## Linus Torvalds, 2005-12-27 19:18 Subject: Re: cannot handle more than 29 refs Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0512271113290.14098%40g5.osdl.org In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2005-12-27 19:46 Subject: Re: cannot handle more than 29 refs Message-ID: <7vvexa9vbu.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvexa9vbu.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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 --- 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. ``` ## Jon Nelson, 2005-12-27 20:49 Subject: Re: cannot handle more than 29 refs Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0512271448130.6812%40gheavc.wnzcbav.cig In-Reply-To: ``` 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 ```