author | Shawn O. Pearce <spearce@spearce.org> | |
Thu, 14 Feb 2008 06:34:43 +0000 (01:34 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sat, 16 Feb 2008 08:47:07 +0000 (00:47 -0800) | ||
commit | 118805b92097e355001bb16687ce252646eab604 | |
tree | 688f2e412aafd1fb32854f26ad1b33514aec1e9d | tree | snapshot |
parent | 3b08e5b8c9130f57a38e51557dbb173b9edda5ba | commit | diff |
Finish current packfile during fast-import crash handler
If fast-import is in the middle of crashing due to a protocol error
or something like that then it can be very useful to have the mark
table and all objects up until that point be available for a new
import to resume from.
Currently we just close the active packfile, unkeep all of our
newly created packfiles (so they can be deleted), and dump the
marks table to a temporary file.
We don't attempt to update the refs/tags that the process has in
memory as much of that data can be found in the crash report and I'm
not sure it would be the right thing to do under every type of crash.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If fast-import is in the middle of crashing due to a protocol error
or something like that then it can be very useful to have the mark
table and all objects up until that point be available for a new
import to resume from.
Currently we just close the active packfile, unkeep all of our
newly created packfiles (so they can be deleted), and dump the
marks table to a temporary file.
We don't attempt to update the refs/tags that the process has in
memory as much of that data can be found in the crash report and I'm
not sure it would be the right thing to do under every type of crash.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import.c | diff | blob | history |