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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
