From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Mon, 09 Feb 2009 02:26:42 GMT
Subject: "repack" when a needed commit object missing "kills" the repo
Message-ID: <20090209022642.GA19413@atjola.homenet>

Hi,

I have a git-svn repo with a large grafts file to recreate merges done
in svn and in one case to simply change a commit's parent. I don't
recall the reason for the latter, it's been there for almost a year now,
probably some crap from the svn repo that I didn't want to have in my
git history. So the original history was like:

A---B---C

And the graft turns that into:

A---C

Earlier repacks seem to have already pruned the B commit object, so
removing the grafts correctly causes git to complain about that missing
object.

Now I decided to finally run filter-branch on that repo to get rid of
the huge grafts file. So I ran "git filter-branch -- --all", removed the
grafts file, dropped all the refs/original/ stuff and went on to "git
repack -adf". And when that finished, a _lot_ of objects were suddenly
missing, including some of the rewritten commits --> repo busted.
Fortunately I had made a backup. :-)

The pack-objects process complained about the B commit object that was
already missing earlier, and after some time I realised that I didn't
expire the reflogs, so the "broken" commit was still reachable through
them. So I retried with the reflogs empty, and yup, that worked well. So
missing objects seem to confuse pack-objects enough to stop it from
packing all of objects reachable through non-broken chains.

A backtrace from the point at which pack-objects complains about the
missing object shows this:

#0  error (err=0x4bff35 "Could not read %s") at usage.c:64
#1  0x0000000000459e3c in parse_commit (item=0x15f8c50) at commit.c:304
#2  0x000000000048d2ea in add_parents_to_list (revs=0x7fff5f8bd7c0, 
    commit=0x15f8a10, list=0x7fff5f8bd7c0, cache_ptr=0x0) at revision.c:514
#3  0x000000000048d75d in get_revision_1 (revs=0x7fff5f8bd7c0)
    at revision.c:1740
#4  0x000000000048d7cb in get_revision_internal (revs=0x7fff5f8bd7c0)
    at revision.c:1843
#5  0x000000000048da31 in get_revision (revs=0x7fff5f8bd7c0) at revision.c:1924
#6  0x0000000000471f0c in traverse_commit_list (revs=0x7fff5f8bd7c0, 
    show_commit=0x437ec0 <show_commit>, show_object=0x437e80 <show_object>)
    at list-objects.c:147
#7  0x0000000000437fc8 in get_object_list (ac=<value optimized out>, 
    av=<value optimized out>) at builtin-pack-objects.c:2059
#8  0x000000000043aa4e in cmd_pack_objects (argc=6, argv=0x7fff5f8bde38, 
    prefix=<value optimized out>) at builtin-pack-objects.c:2288
#9  0x0000000000404983 in handle_internal_command (argc=6, argv=0x7fff5f8bde38)
    at git.c:244
#10 0x0000000000404eb6 in main (argc=6, argv=0x7fff5f8bde38) at git.c:473

Maybe get_revision_internal() switching into boundary mode is bad there?
The failing parse_commit() call causes get_revision_1() to return NULL,
so get_revision_internal() assumes it ran out of commits, but in this
case, it "just" hit a bad commit.

Up to now, I don't have a small reproduction case yet and unfortunately
I can't make the repo with which I've seen the failure available.

Thanks,
Björn