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>
Linus TorvaldsRe: cannot handle more than 29 refs
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 HamanoRe: cannot handle more than 29 refs
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
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>