{"thread":{"id":"7970","subject":"repack: handling of .keep files","startedAt":"2007-05-04T09:25:20Z","lastAt":"2007-05-07T21:59:49Z","messageCount":11,"participants":["Alex Riesen","Junio C Hamano","Nicolas Pitre","Dana How"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41026","messageId":"81b0412b0705040225p26679dbib6a1261a1a43ee67@mail.gmail.com","threadId":"7970","inReplyTo":null,"subject":"repack: handling of .keep files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T09:25:20Z","receivedAt":"2007-05-04T09:25:20Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"It does not seem to be consistent with the name:\n\"git repack -a -d\" removes .keep files anyway.\n\nHow can I pin down a pack file so that it is never repacked?\n(Windows doesn't like big files, they get fragmented heavily\nand are hard to read and defragment. So I try keep them\nrelatively small).\n\nP.S. Experimenting with the .keep-files I had a crash in git-log,\nwhen the pack was renamed into .keep.pack, but the\nindex was not. git-log complained about two objects it could not\nread and than crashed. It's cygwin.\n"},{"id":"41030","messageId":"7vy7k4ud3d.fsf@assigned-by-dhcp.cox.net","threadId":"7970","inReplyTo":"81b0412b0705040225p26679dbib6a1261a1a43ee67@mail.gmail.com","subject":"Re: repack: handling of .keep files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T09:56:06Z","receivedAt":"2007-05-04T09:56:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" <raa.lkml@gmail.com> writes:\n\n> ... Experimenting with the .keep-files I had a crash in git-log,\n> when the pack was renamed into .keep.pack, but the\n> index was not. git-log complained about two objects it could not\n> read and than crashed. It's cygwin.\n\nThis part makes me suspect you are not even using the .keep\nproperly.  In addition to pack-[0-9a-f]{40}.(pack|idx), you\nwould have a corresponding pack-[0-9a-f]{40}.keep file (whose\ncontents does not matter) to mark that these should not get\nrepacked.\n"},{"id":"41033","messageId":"81b0412b0705040342p4fed3a4bnee92cce6b5fb6b9@mail.gmail.com","threadId":"7970","inReplyTo":"7vy7k4ud3d.fsf@assigned-by-dhcp.cox.net","subject":"Re: repack: handling of .keep files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T10:42:10Z","receivedAt":"2007-05-04T10:42:10Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Alex Riesen\" <raa.lkml@gmail.com> writes:\n>\n> > ... Experimenting with the .keep-files I had a crash in git-log,\n> > when the pack was renamed into .keep.pack, but the\n> > index was not. git-log complained about two objects it could not\n> > read and than crashed. It's cygwin.\n>\n> This part makes me suspect you are not even using the .keep\n> properly.  In addition to pack-[0-9a-f]{40}.(pack|idx), you\n> would have a corresponding pack-[0-9a-f]{40}.keep file (whose\n> contents does not matter) to mark that these should not get\n> repacked.\n\nThis is it (described in git-index-pack.txt, maybe git-repack.txt should\nreference it too), thanks.\n\nStill, git-log shouldn't crash (nothing should, of course).\nAnd, the temporary pack is created in working tree, instead of in GIT_DIR\n(why not GIT_OBJECT_DIR, btw?)\n"},{"id":"41066","messageId":"7vslacttij.fsf@assigned-by-dhcp.cox.net","threadId":"7970","inReplyTo":"81b0412b0705040342p4fed3a4bnee92cce6b5fb6b9@mail.gmail.com","subject":"Re: repack: handling of .keep files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T16:59:00Z","receivedAt":"2007-05-04T16:59:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" <raa.lkml@gmail.com> writes:\n\n> Still, git-log shouldn't crash (nothing should, of course).\n\nHonestly, I think that's borderline.  If you \"dd if=/dev/random\nof=/dev/hda\", should the kernel keep going, perhaps gracefully\ndeclining access to the filesystem on that drive?\n\n> And, the temporary pack is created in working tree, instead of in GIT_DIR\n> (why not GIT_OBJECT_DIR, btw?)\n\nNot limited to the temporary pack (the detail of exact use\npattern escapes me -- I do not think it was temporary pack that\ninitiated the use of GIT_DIR for temporary things), I think\ntrying to not create things in the working tree came after\nsomebody who had a read-only (to him, not necessarily to\neverybody) working tree and read-write GIT_DIR (separate\nlocation, specified with the environment variable) had trouble.\nAt least the theory was GIT_DIR would be writable as long as you\nare doing a \"write\" oriented operation, regardless of what.\n\nBack then we did not support working in subdirectory of the\nproject as fully as we do now, so using such configuration was\nnot much less convenient than you have the normal layout of\nhaving $project/.git directory at the top of the working tree.\n\nWhile I do not think it is worth to try \"supporting\" use of\nread-only working tree for write oriented operations, which\nmeans that it should be safe to assume that the working tree is\nwritable and we _could_ create temporary pack in working tree\ninstead, I do not think the \"_could_\" means we should.  In the\ncase of temporary pack I do not think there would be a risk of\nfilename collisions, I think it makes sense to use either\nGIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.  \n\nI do not know pros-and-cons between .git/ and .git/objects/;\nfilesystems tend to cluster nearby things better, so the latter\nmight be more logical, but packs are about using smaller (much\nmuch much smaller) number of files than you would use otherwise\nto store objects _and_ keeping them in use, so I suspect it\nwould not make much practical difference even if we try to\nencourage the filesystem to allocate the disk blocks for new\npack near existing packs by creating the temporary file.\n"},{"id":"41070","messageId":"81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com","threadId":"7970","inReplyTo":"7vslacttij.fsf@assigned-by-dhcp.cox.net","subject":"Re: repack: handling of .keep files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T17:24:50Z","receivedAt":"2007-05-04T17:24:50Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Alex Riesen\" <raa.lkml@gmail.com> writes:\n>\n> > Still, git-log shouldn't crash (nothing should, of course).\n>\n> Honestly, I think that's borderline.  If you \"dd if=/dev/random\n> of=/dev/hda\", should the kernel keep going, perhaps gracefully\n> declining access to the filesystem on that drive?\n\ne2fsck has a test somewhere which randomly corrupts a partition\nand then lets the program fix it.\nAll kind of corruptions happen, we will have to deal with them.\nEspecially if this crash is so simple to reproduce.\n\n> case of temporary pack I do not think there would be a risk of\n> filename collisions, I think it makes sense to use either\n> GIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.\n>\n> I do not know pros-and-cons between .git/ and .git/objects/;\n\nThese are settable separately, so theoretically you can end\nup with .git and .git/objects being on different filesystems.\nAtomic rename wont be possible than.\n"},{"id":"41077","messageId":"7v6478tmyy.fsf@assigned-by-dhcp.cox.net","threadId":"7970","inReplyTo":"81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com","subject":"Re: repack: handling of .keep files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T19:20:21Z","receivedAt":"2007-05-04T19:20:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" <raa.lkml@gmail.com> writes:\n\n> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:\n> ...\n>> I do not know pros-and-cons between .git/ and .git/objects/;\n>\n> These are settable separately, so theoretically you can end\n> up with .git and .git/objects being on different filesystems.\n> Atomic rename wont be possible than.\n\nFair enough.\n\nAs we've lived without trouble long enough creating the new pack\ntempfile in $GIT_DIR, I do not think it is urgent; but feel free\nto propose moving it to GIT_OBJECT_DIRECTORY.  We _might_ need\nto teach fsck to take notice of such leftover temporary files\nfrom an earlier, aborted run if we do this -- I haven't looked.\n"},{"id":"41081","messageId":"alpine.LFD.0.99.0705041539250.24220@xanadu.home","threadId":"7970","inReplyTo":"81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com","subject":"Re: repack: handling of .keep files","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-04T19:40:32Z","receivedAt":"2007-05-04T19:40:32Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 4 May 2007, Alex Riesen wrote:\n\n> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:\n> > \"Alex Riesen\" <raa.lkml@gmail.com> writes:\n> > \n> > > Still, git-log shouldn't crash (nothing should, of course).\n> > \n> > Honestly, I think that's borderline.  If you \"dd if=/dev/random\n> > of=/dev/hda\", should the kernel keep going, perhaps gracefully\n> > declining access to the filesystem on that drive?\n> \n> e2fsck has a test somewhere which randomly corrupts a partition\n> and then lets the program fix it.\n> All kind of corruptions happen, we will have to deal with them.\n> Especially if this crash is so simple to reproduce.\n> \n> > case of temporary pack I do not think there would be a risk of\n> > filename collisions, I think it makes sense to use either\n> > GIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.\n> > \n> > I do not know pros-and-cons between .git/ and .git/objects/;\n> \n> These are settable separately, so theoretically you can end\n> up with .git and .git/objects being on different filesystems.\n> Atomic rename wont be possible than.\n\nOther temporary pack/object creation instances already use \nGIT_OBJECT_DIRECTORY.\n\n\nNicolas\n"},{"id":"41096","messageId":"20070504215457.GE4033@steel.home","threadId":"7970","inReplyTo":"81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com","subject":"[PATCH] Handle return code of parse_commit in revision machinery","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T21:54:57Z","receivedAt":"2007-05-04T21:54:57Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"This fixes a crash in broken repositories where random commits\nsuddenly disappear.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\n... For example when loosing one of the packs by renaming it into a\nrandom name while trying to figure out how to protect it from deletion\nby \"git-repack -a -d\". Lesson learned, code fixed, tests passed.\n\n revision.c |   75 +++++++++++++++++++++++++++++++++++++++++------------------\n revision.h |    2 +-\n 2 files changed, 53 insertions(+), 24 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex e60a26c..b4c494d 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -318,7 +318,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \twhile ((parent = *pp) != NULL) {\n \t\tstruct commit *p = parent->item;\n \n-\t\tparse_commit(p);\n+\t\tif (parse_commit(p) < 0)\n+\t\t\tdie(\"cannot simplify commit %s (because of %s)\",\n+\t\t\t    sha1_to_hex(commit->object.sha1),\n+\t\t\t    sha1_to_hex(p->object.sha1));\n \t\tswitch (rev_compare_tree(revs, p->tree, commit->tree)) {\n \t\tcase REV_TREE_SAME:\n \t\t\ttree_same = 1;\n@@ -347,7 +350,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\t\t\t * IOW, we pretend this parent is a\n \t\t\t\t * \"root\" commit.\n \t\t\t\t */\n-\t\t\t\tparse_commit(p);\n+\t\t\t\tif(parse_commit(p) < 0)\n+\t\t\t\t\tdie(\"cannot simplify commit %s (invalid %s)\",\n+\t\t\t\t\t    sha1_to_hex(commit->object.sha1),\n+\t\t\t\t\t    sha1_to_hex(p->object.sha1));\n \t\t\t\tp->parents = NULL;\n \t\t\t}\n \t\t/* fallthrough */\n@@ -362,14 +368,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\tcommit->object.flags |= TREECHANGE;\n }\n \n-static void add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)\n+static int add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)\n {\n \tstruct commit_list *parent = commit->parents;\n \tunsigned left_flag;\n \tint add, rest;\n \n \tif (commit->object.flags & ADDED)\n-\t\treturn;\n+\t\treturn 0;\n \tcommit->object.flags |= ADDED;\n \n \t/*\n@@ -388,7 +394,8 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\twhile (parent) {\n \t\t\tstruct commit *p = parent->item;\n \t\t\tparent = parent->next;\n-\t\t\tparse_commit(p);\n+\t\t\tif (parse_commit(p) < 0)\n+\t\t\t\treturn -1;\n \t\t\tp->object.flags |= UNINTERESTING;\n \t\t\tif (p->parents)\n \t\t\t\tmark_parents_uninteresting(p);\n@@ -397,7 +404,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\t\tp->object.flags |= SEEN;\n \t\t\tinsert_by_date(p, list);\n \t\t}\n-\t\treturn;\n+\t\treturn 0;\n \t}\n \n \t/*\n@@ -409,7 +416,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\trevs->prune_fn(revs, commit);\n \n \tif (revs->no_walk)\n-\t\treturn;\n+\t\treturn 0;\n \n \tleft_flag = (commit->object.flags & SYMMETRIC_LEFT);\n \n@@ -418,7 +425,8 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\tstruct commit *p = parent->item;\n \n \t\tparent = parent->next;\n-\t\tparse_commit(p);\n+\t\tif (parse_commit(p) < 0)\n+\t\t\treturn -1;\n \t\tp->object.flags |= left_flag;\n \t\tif (p->object.flags & SEEN)\n \t\t\tcontinue;\n@@ -426,6 +434,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\tif (add)\n \t\t\tinsert_by_date(p, list);\n \t}\n+\treturn 0;\n }\n \n static void cherry_pick_list(struct commit_list *list)\n@@ -508,7 +517,7 @@ static void cherry_pick_list(struct commit_list *list)\n \tfree_patch_ids(&ids);\n }\n \n-static void limit_list(struct rev_info *revs)\n+static int limit_list(struct rev_info *revs)\n {\n \tstruct commit_list *list = revs->commits;\n \tstruct commit_list *newlist = NULL;\n@@ -524,7 +533,8 @@ static void limit_list(struct rev_info *revs)\n \n \t\tif (revs->max_age != -1 && (commit->date < revs->max_age))\n \t\t\tobj->flags |= UNINTERESTING;\n-\t\tadd_parents_to_list(revs, commit, &list);\n+\t\tif (add_parents_to_list(revs, commit, &list) < 0)\n+\t\t\treturn -1;\n \t\tif (obj->flags & UNINTERESTING) {\n \t\t\tmark_parents_uninteresting(commit);\n \t\t\tif (everybody_uninteresting(list))\n@@ -539,6 +549,7 @@ static void limit_list(struct rev_info *revs)\n \t\tcherry_pick_list(newlist);\n \n \trevs->commits = newlist;\n+\treturn 0;\n }\n \n struct all_refs_cb {\n@@ -1227,7 +1238,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \treturn left;\n }\n \n-void prepare_revision_walk(struct rev_info *revs)\n+int prepare_revision_walk(struct rev_info *revs)\n {\n \tint nr = revs->pending.nr;\n \tstruct object_array_entry *e, *list;\n@@ -1249,42 +1260,59 @@ void prepare_revision_walk(struct rev_info *revs)\n \tfree(list);\n \n \tif (revs->no_walk)\n-\t\treturn;\n+\t\treturn 0;\n \tif (revs->limited)\n-\t\tlimit_list(revs);\n+\t\tif (limit_list(revs) < 0)\n+\t\t\treturn -1;\n \tif (revs->topo_order)\n \t\tsort_in_topological_order_fn(&revs->commits, revs->lifo,\n \t\t\t\t\t     revs->topo_setter,\n \t\t\t\t\t     revs->topo_getter);\n+\treturn 0;\n }\n \n-static int rewrite_one(struct rev_info *revs, struct commit **pp)\n+enum rewrite_result\n+{\n+\trewrite_one_ok,\n+\trewrite_one_noparents,\n+\trewrite_one_error,\n+};\n+\n+static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp)\n {\n \tfor (;;) {\n \t\tstruct commit *p = *pp;\n \t\tif (!revs->limited)\n-\t\t\tadd_parents_to_list(revs, p, &revs->commits);\n+\t\t\tif (add_parents_to_list(revs, p, &revs->commits) < 0)\n+\t\t\t\treturn rewrite_one_error;\n \t\tif (p->parents && p->parents->next)\n-\t\t\treturn 0;\n+\t\t\treturn rewrite_one_ok;\n \t\tif (p->object.flags & (TREECHANGE | UNINTERESTING))\n-\t\t\treturn 0;\n+\t\t\treturn rewrite_one_ok;\n \t\tif (!p->parents)\n-\t\t\treturn -1;\n+\t\t\treturn rewrite_one_noparents;\n \t\t*pp = p->parents->item;\n \t}\n }\n \n-static void rewrite_parents(struct rev_info *revs, struct commit *commit)\n+static int rewrite_parents(struct rev_info *revs, struct commit *commit)\n {\n \tstruct commit_list **pp = &commit->parents;\n \twhile (*pp) {\n \t\tstruct commit_list *parent = *pp;\n-\t\tif (rewrite_one(revs, &parent->item) < 0) {\n+\t\tswitch (rewrite_one(revs, &parent->item))\n+\t\t{\n+\t\tcase rewrite_one_ok:\n+\t\t\tbreak;\n+\t\tcase rewrite_one_noparents:\n \t\t\t*pp = parent->next;\n \t\t\tcontinue;\n+\t\tcase rewrite_one_error:\n+\t\t\treturn -1;\n \t\t}\n \t\tpp = &parent->next;\n \t}\n+\treturn 0;\n }\n \n static int commit_match(struct commit *commit, struct rev_info *opt)\n@@ -1320,7 +1348,8 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\t\tif (revs->max_age != -1 &&\n \t\t\t    (commit->date < revs->max_age))\n \t\t\t\tcontinue;\n-\t\t\tadd_parents_to_list(revs, commit, &revs->commits);\n+\t\t\tif (add_parents_to_list(revs, commit, &revs->commits) < 0)\n+\t\t\t\treturn NULL;\n \t\t}\n \t\tif (commit->object.flags & SHOWN)\n \t\t\tcontinue;\n@@ -1348,8 +1377,8 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\t\t\tif (!commit->parents || !commit->parents->next)\n \t\t\t\t\tcontinue;\n \t\t\t}\n-\t\t\tif (revs->parents)\n-\t\t\t\trewrite_parents(revs, commit);\n+\t\t\tif (revs->parents && rewrite_parents(revs, commit) < 0)\n+\t\t\t\treturn NULL;\n \t\t}\n \t\treturn commit;\n \t} while (revs->commits);\ndiff --git a/revision.h b/revision.h\nindex cdf94ad..2845167 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -113,7 +113,7 @@ extern void init_revisions(struct rev_info *revs, const char *prefix);\n extern int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def);\n extern int handle_revision_arg(const char *arg, struct rev_info *revs,int flags,int cant_be_filename);\n \n-extern void prepare_revision_walk(struct rev_info *revs);\n+extern int prepare_revision_walk(struct rev_info *revs);\n extern struct commit *get_revision(struct rev_info *revs);\n \n extern void mark_parents_uninteresting(struct commit *commit);\n-- \n1.5.2.rc1.21.g80e79\n"},{"id":"41348","messageId":"56b7f5510705071051l75d701d7r94b7c4629cc425f@mail.gmail.com","threadId":"7970","inReplyTo":"20070507173324.GA3436@steel.home","subject":"Re: [PATCH] Use GIT_OBJECT_DIR for temporary files of pack-objects","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-07T17:51:24Z","receivedAt":"2007-05-07T17:51:24Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:\n> I'm not sure about fsck cleaning up after crashed/killed pack-objects:\n> not sure I _can_ detect if the temp files really are just leftovers.\n\nIt looks like you create temp file in objects , not objects/pack .\n\nSo a rule could be : packs left in the former are crashed/killed,\nand packs in the latter are complete?\n\nYou should also look at $PACKTMP in git-repack.sh .\nIn it $GIT_DIR should probably be $GIT_OBJECT_DIRECTORY ?\n\nJunio:\nThis patch touches the same lines as the --max-pack-size patch.\nWhat do you want to do with the latter?\n\nThanks,\n-- \nDana L. How  danahow@gmail.com  +1 650 804 5991 cell\n"},{"id":"41368","messageId":"20070507213347.GB3436@steel.home","threadId":"7970","inReplyTo":"56b7f5510705071051l75d701d7r94b7c4629cc425f@mail.gmail.com","subject":"Re: [PATCH] Use GIT_OBJECT_DIR for temporary files of pack-objects","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-07T21:33:47Z","receivedAt":"2007-05-07T21:33:47Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Mon, May 07, 2007 19:51:24 +0200:\n> On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:\n> >I'm not sure about fsck cleaning up after crashed/killed pack-objects:\n> >not sure I _can_ detect if the temp files really are just leftovers.\n> \n> It looks like you create temp file in objects , not objects/pack .\n> \n> So a rule could be : packs left in the former are crashed/killed,\n> and packs in the latter are complete?\n\nHow do you know for sure that they are _left_ already?\n\n> You should also look at $PACKTMP in git-repack.sh .\n> In it $GIT_DIR should probably be $GIT_OBJECT_DIRECTORY ?\n\nI think it should, but it is already not the working directory, so my\noriginal complaint does not apply\n"},{"id":"41370","messageId":"56b7f5510705071459pceb8590j47bde5cc6a3e60a0@mail.gmail.com","threadId":"7970","inReplyTo":"20070507213347.GB3436@steel.home","subject":"Re: [PATCH] Use GIT_OBJECT_DIR for temporary files of pack-objects","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-07T21:59:49Z","receivedAt":"2007-05-07T21:59:49Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:\n> Dana How, Mon, May 07, 2007 19:51:24 +0200:\n> > On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:\n> > >I'm not sure about fsck cleaning up after crashed/killed pack-objects:\n> > >not sure I _can_ detect if the temp files really are just leftovers.\n> >\n> > It looks like you create temp file in objects , not objects/pack .\n> >\n> > So a rule could be : packs left in the former are crashed/killed,\n> > and packs in the latter are complete?\n>\n> How do you know for sure that they are _left_ already?\nAh, e.g. you're packing and fsck'ing at the same time?\nThen you can't know.  Never mind...\n\n> > You should also look at $PACKTMP in git-repack.sh .\n> > In it $GIT_DIR should probably be $GIT_OBJECT_DIRECTORY ?\n>\n> I think it should, but it is already not the working directory, so my\n> original complaint does not apply\nOK, if I have to further change my --max-pack-size patchset\nwhich touches git-repack.sh, I'll roll this in.\n\nThanks,\n-- \nDana L. How  danahow@gmail.com  +1 650 804 5991 cell\n"}]}