]> git.ipfire.org Git - thirdparty/git.git/commit - fast-import.c
Fix possible coredump with fast-import --import-marks
authorShawn O. Pearce <spearce@spearce.org>
Thu, 24 May 2007 04:32:31 +0000 (00:32 -0400)
committerShawn O. Pearce <spearce@spearce.org>
Thu, 24 May 2007 04:50:19 +0000 (00:50 -0400)
commitaac65ed1bc63619d32516079995f5cbe4bb46492
tree47ca2263c1c34a67e7ea0a9f5751272ae41c2832
parent654aaa37ab5c70650bdd16d57b56c2d0f9aa43cf
Fix possible coredump with fast-import --import-marks

When e8438420bb7d368bec3647b90c557b9931582267 allowed us to reload
the marks table on subsequent runs of fast-import we really broke
things, as we set pack_id to MAX_PACK_ID for any objects we imported
into the marks table.  Creating a branch from that mark should fail
as we attempt to read the object through a non-existant packed_git
pointer.  Instead we have to use the normal Git object system to
locate the older commit, as we ourselves do not have a reference
to the packed_git it resides in.

This bug only occurred because t9300 was not complete enough.
When we added the --import-marks feature we didn't actually test
its implementation enough to verify the function worked as intended.
I have corrected that, and included the changes as part of this fix.
Prior versions of fast-import fail the new test(s); this commit
allows them to pass.

Credit for this bug find goes to Simon Hausmann <simon@lst.de> as
he recently identified a similiar bug in the tree lazy-loading path.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import.c
t/t9300-fast-import.sh