fatal: Could not parse object ...

[dabrahams]

This problem with Git has occurred with other projects, e.g.  Capistrano and  Chef.

The problem appears to be the -t  here, which is unfortunate... but it should be possible to fix this entirely on the master side by making the slave side run ordinary shell commands, shouldn't it?

[dabrahams]

Background:

• git fetch -t is the same as git fetch --tags
• the links labeled Capistrano and Chef actually point at the tickets where those projects explain and fixed the same problem
• see  http://bbot.boostpro.com/builders/Boost.Modularize-x-Modularize/builds/69/steps/Git(boost)/logs/stdio for an example of the problem's effects

[dustin]

OK, so it looks like it's possible that the rev being built is only reachable from a branch, and not from a tag, in which case fetch --tags doesn't fetch the relevant commit. I see the comments on the stackoverflow thread, too.

However, I think that the use of '+master' fixes this. At least, it does for me. In a repository that was somewhat behind upstream, I ran

dustin@euclid ~/code/amanda/t/amanda [master] $ git fetch --tags zmanda +master
remote: Counting objects: 153, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 114 (delta 92), reused 80 (delta 62)
Receiving objects: 100% (114/114), 32.75 KiB, done.
Resolving deltas: 100% (92/92), completed with 35 local objects.
From http://github.com/zmanda/amanda
 * branch            master     -> FETCH_HEAD
dustin@euclid ~/code/amanda/t/amanda [master] $ git reset --hard dcf864
HEAD is now at dcf8647 * perl/Amanda/Taper/Scribe.pm: Correcly make label with meta and barcode

where dcf864 is the current rev of master at zmanda/amanda, and was a commit that wasn't in my repo before that time. That rev is also not referenced by any tags in my repo or zmanda/amanda. So there's something about this problem that I'm still missing here - any idea how to explain what I'm seeing?

[dabrahams]

Maybe the problem is that I'm interested in all the branches, not just master?

[dustin]

The commit you linked to was on master - or at least, the change says so. If the change contains incorrect information, I think all bets are off..

[dabrahams]

regardless, anything you do that's specific to master (like adding +master) can't possibly constitute a general fix, can it?

[dabrahams]

While I think comment:5 is worth thinking about, I'm happy/sorry to report that I think this is all a result of a multi-repository configuration where we're trying to check out the changes for one repo from a different repo. I'll have to backtrack and implement the more-principled multi-repo approach I've been designing. Sorry for the trouble.

[dustin]

It doesn't add +master automatically - that's the branch from the change/sourcestamp.

But yes, I think that this is one of the places where multi-repo builds don't work well. Sorry about that :(