repack: implement `--expire-to` option
cover repack: implement `--expire-to` option
This series polishes off the RFC [1] I sent over the summer teaching git repack how to move pruned objects into a separate cruft pack in a different repository.
We've been using this series at GitHub for some time now as an escape-hatch mechanism for quickly recovering pruned objects that run afoul of the "advertise-then-prune" race described in [2].
The general idea is that we write out a second cruft pack to capture the pruned objects, with two minor changes:
- The second cruft pack counts the first cruft pack as "saved", meaning that we'll exclude its objects (thus ignoring both reachable and unreachable-but-recent objects from the second cruft pack).
- The second cruft pack does *not* exclude objects based on age (i.e., it acts as if --cruft-expiration=never were given) so as to avoid excluding objects which are being pruned due to their age.
The first few patches are preparatory, and the substantive change is implemented in the fourth patch. I would suggest that reviewers start there, and then read the first three patches.
Since this series basically boils down to adding one new conditional, like:
if (delete_redundant && expire_to) {
ret = write_cruft_pack(...):
if (ret)
return ret;
}The (second) call to write_cruft_pack() comes with a rather extensive inline comment explaining what is going on ;-).
Thanks in advance for your review.
[1]: https://lore.kernel.org/git/[email protected]/
[2]: https://lore.kernel.org/git/[email protected]/
Taylor Blau (4):
builtin/repack.c: pass "out" to prepare_pack_objects builtin/repack.c: pass "cruft_expiration" to write_cruft_pack builtin/repack.c: write cruft packs to arbitrary locations builtin/repack.c: implement --expire-to for storing pruned objects
Documentation/git-repack.txt | 6 ++ builtin/repack.c | 67 ++++++++++++++++--- t/t7700-repack.sh | 121 +++++++++++++++++++++++++++++++++++ 3 files changed, 186 insertions(+), 8 deletions(-)
Signature · 1 line
2.38.0.16.g393fd4c6db
PATCH 1/4 builtin/repack.c: pass "out" to `prepare_pack_objects`
builtin/repack.c's prepare_pack_objects() is used to prepare a set of arguments to a pack-objects process which will generate a desired pack.
A future patch will add an --expire-to option which allows git repack to write a cruft pack containing the pruned objects out to a separate repository. Prepare for this by teaching that function to write packs to an arbitrary location specified by the caller.
All existing callers of prepare_pack_objects() will pass packtmp for out, retaining the existing behavior.
--- builtin/repack.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
builtin/repack.c +6 -5
@@ -188,7 +188,8 @@ static void remove_redundant_pack(const char *dir_name, const char *base_name) }static void prepare_pack_objects (struct child_process *cmd, -const struct pack_objects_args *args) +const struct pack_objects_args *args, +const char *out) {strvec_push (&cmd->args,"pack-objects" );if (args->window)
@@ -211,7 +212,7 @@ static void prepare_pack_objects(struct child_process *cmd,strvec_push (&cmd->args,"--quiet" );if (delta_base_offset)strvec_push (&cmd->args,"--delta-base-offset" ); -strvec_push (&cmd->args, packtmp); +strvec_push (&cmd->args, out); cmd->git_cmd =1 ; cmd->out =-1 ; }
@@ -275,7 +276,7 @@ static void repack_promisor_objects(const struct pack_objects_args *args,FILE *out;struct strbuf line =STRBUF_INIT ; -prepare_pack_objects (&cmd, args); +prepare_pack_objects (&cmd, args, packtmp); cmd.in =-1 ;/*
@@ -673,7 +674,7 @@ static int write_cruft_pack(const struct pack_objects_args *args,FILE *in, *out;int ret; -prepare_pack_objects (&cmd, args); +prepare_pack_objects (&cmd, args, packtmp);strvec_push (&cmd.args,"--cruft" );if (cruft_expiration)
@@ -861,7 +862,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)sigchain_push_common (remove_pack_on_signal); -prepare_pack_objects (&cmd, &po_args); +prepare_pack_objects (&cmd, &po_args, packtmp); show_progress = !po_args.quiet &&isatty (2 );
Signature · 1 line
2.38.0.16.g393fd4c6db
Re: [PATCH 1/4] builtin/repack.c: pass "out" to `prepare_pack_objects`
Quoted 11 lines · Taylor Blau
builtin/repack.c'sprepare_pack_objects()is used to prepare a set of arguments to apack-objectsprocess which will generate a desired pack.A future patch will add an
--expire-tooption which allowsgit repackto write a cruft pack containing the pruned objects out to a separate repository. Prepare for this by teaching that function to write packs to an arbitrary location specified by the caller.All existing callers of
prepare_pack_objects()will passpacktmpforout, retaining the existing behavior.
It does make sense to allow the caller to specify the name of the temporary file to be used, but is "out" a good name for that? The other two arguments are self explanatory both by their type and the name, but this is of type "const char *" that does not convey what the string is about at all, so giging a good name to the parameter is more important than for others.
The patch text itself is very straight-forward. Thanks.
Quoted 42 lines
static void prepare_pack_objects(struct
child_process*cmd,builtin/repack.c +6
-5- const struct pack_objects_args *args) +const struct pack_objects_args *args, + const char *out) { strvec_push(&cmd->args, "pack-objects");if (args->window)@@ -211,7 +212,7 @@ static void prepare_pack_objects(struct child_process *cmd,strvec_push (&cmd->args,"--quiet" );if (delta_base_offset)strvec_push (&cmd->args,"--delta-base-offset" ); -strvec_push (&cmd->args, packtmp); +strvec_push (&cmd->args, out); cmd->git_cmd =1 ; cmd->out =-1 ; }@@ -275,7 +276,7 @@ static void repack_promisor_objects(const struct pack_objects_args *args,FILE *out;struct strbuf line =STRBUF_INIT ; -prepare_pack_objects (&cmd, args); +prepare_pack_objects (&cmd, args, packtmp); cmd.in =-1 ;/* @@ -673,7 +674,7 @@ static int write_cruft_pack(const struct pack_objects_args *args,FILE *in, *out;int ret; -prepare_pack_objects (&cmd, args); +prepare_pack_objects (&cmd, args, packtmp);strvec_push (&cmd.args,"--cruft" );if (cruft_expiration)@@ -861,7 +862,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)sigchain_push_common (remove_pack_on_signal); -prepare_pack_objects (&cmd, &po_args); +prepare_pack_objects (&cmd, &po_args, packtmp); show_progress = !po_args.quiet &&isatty (2 );
Re: [PATCH 1/4] builtin/repack.c: pass "out" to `prepare_pack_objects`
Quoted 14 lines · Junio C Hamano
Quoted 11 lines · Taylor Blau
builtin/repack.c'sprepare_pack_objects()is used to prepare a set of arguments to apack-objectsprocess which will generate a desired pack.A future patch will add an
--expire-tooption which allowsgit repackto write a cruft pack containing the pruned objects out to a separate repository. Prepare for this by teaching that function to write packs to an arbitrary location specified by the caller.All existing callers of
prepare_pack_objects()will passpacktmpforout, retaining the existing behavior.
Quoted 8 lines
It does make sense to allow the caller to specify the name of the temporary file to be used, but is "out" a good name for that? The other two arguments are self explanatory both by their type and the name, but this is of type "const char *" that does not convey what the string is about at all, so giging a good name to the parameter is more important than for others.
The patch text itself is very straight-forward. Thanks.
I agree that the patch is nice and simple.
As for a name, this parameter specifies a file prefix. Perhaps 'pack_prefix' would be a good name for this?
Thanks,
-Stolee
PATCH 2/4 builtin/repack.c: pass "cruft_expiration" to `write_cruft_pack`
In reply to Taylor Blaubuiltin/repack.c's write_cruft_pack() is used to generate the cruft pack when --cruft is supplied. It uses a static variable "cruft_expiration" which is filled in by option parsing.
A future patch will add an --expire-to option which allows git repack to write a cruft pack containing the pruned objects out to a separate repository. In order to implement this functionality, some callers will have to pass a value for cruft_expiration different than the one filled out by option parsing.
Prepare for this by teaching write_cruft_pack to take a "cruft_expiration" parameter, instead of reading a single static variable.
The (sole) existing caller of write_cruft_pack() will pass the value for "cruft_expiration" filled in by option parsing, retaining existing behavior. This means that we can make the variable local to cmd_repack(), and eliminate the static declaration.
--- builtin/repack.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
builtin/repack.c +4 -2
@@ -32,7 +32,6 @@ static int write_bitmaps = -1;static int use_delta_islands;static int run_update_server_info =1 ;static char *packdir, *packtmp_name, *packtmp; -static char *cruft_expiration;static const char *const git_repack_usage[] = {N_ ("git repack [<options>]" ),
@@ -664,6 +663,7 @@ static int write_midx_included_packs(struct string_list *include,static int write_cruft_pack (const struct pack_objects_args *args,const char *pack_prefix, +const char *cruft_expiration,struct string_list *names,struct string_list *existing_packs,struct string_list *existing_kept_packs)
@@ -746,6 +746,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)struct pack_objects_args cruft_po_args = {NULL };int geometric_factor =0 ;int write_midx =0 ; +const char *cruft_expiration =NULL ;struct option builtin_repack_options[] = { OPT_BIT('a', NULL, &pack_everything,
@@ -985,7 +986,8 @@ int cmd_repack(int argc, const char **argv, const char *prefix) cruft_po_args.local = po_args.local; cruft_po_args.quiet = po_args.quiet; - ret =write_cruft_pack (&cruft_po_args, pack_prefix, &names, + ret =write_cruft_pack (&cruft_po_args, pack_prefix, + cruft_expiration, &names, &existing_nonkept_packs, &existing_kept_packs);if (ret)
Signature · 1 line
2.38.0.16.g393fd4c6db
Re: [PATCH 2/4] builtin/repack.c: pass "cruft_expiration" to `write_cruft_pack`
Quoted 10 lines · Taylor Blau
builtin/repack.c'swrite_cruft_pack()is used to generate the cruft pack when--cruftis supplied. It uses a static variable "cruft_expiration" which is filled in by option parsing.A future patch will add an
--expire-tooption which allowsgit repackto write a cruft pack containing the pruned objects out to a separate repository. In order to implement this functionality, some callers will have to pass a value forcruft_expirationdifferent than the one filled out by option parsing.
Quoted 8 lines
Prepare for this by teaching
write_cruft_packto take a "cruft_expiration" parameter, instead of reading a single static variable.The (sole) existing caller of
write_cruft_pack()will pass the value for "cruft_expiration" filled in by option parsing, retaining existing behavior. This means that we can make the variable local tocmd_repack(), and eliminate the static declaration.
Looks good to me.
PATCH 3/4 builtin/repack.c: write cruft packs to arbitrary locations
In reply to Taylor BlauIn the following commit, a new write_cruft_pack() caller will be added which wants to write a cruft pack to an arbitrary location. Prepare for this by adding a parameter which controls the destination of the cruft pack.
For now, provide "packtmp" so that this commit does not change any behavior.
--- builtin/repack.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
builtin/repack.c +11 -3
@@ -662,6 +662,7 @@ static int write_midx_included_packs(struct string_list *include, } static int write_cruft_pack(const struct pack_objects_args *args, + const char *destination, const char *pack_prefix, const char *cruft_expiration, struct string_list *names,
@@ -673,8 +674,10 @@ static int write_cruft_pack(const struct pack_objects_args *args,struct string_list_item *item;FILE *in, *out;int ret; +const char *scratch; +int local =skip_prefix (destination, packdir, &scratch); -prepare_pack_objects (&cmd, args, packtmp); +prepare_pack_objects (&cmd, args, destination);strvec_push (&cmd.args,"--cruft" );if (cruft_expiration)
@@ -714,7 +717,12 @@ static int write_cruft_pack(const struct pack_objects_args *args,if (line.len != the_hash_algo->hexsz)die (_ ("repack: Expecting full hex object ID lines only " "from pack-objects." )); -string_list_append (names, line.buf); +/* +* avoid putting packs written outside of the repository in the +* list of names +*/ +if (local) +string_list_append (names, line.buf); }fclose (out);
@@ -986,7 +994,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix) cruft_po_args.local = po_args.local; cruft_po_args.quiet = po_args.quiet; - ret =write_cruft_pack (&cruft_po_args, pack_prefix, + ret =write_cruft_pack (&cruft_po_args, packtmp, pack_prefix, cruft_expiration, &names, &existing_nonkept_packs, &existing_kept_packs);
Signature · 1 line
2.38.0.16.g393fd4c6db
Re: [PATCH 3/4] builtin/repack.c: write cruft packs to arbitrary locations
Quoted 26 lines · Taylor Blau
In the following commit, a new
write_cruft_pack()caller will be added which wants to write a cruft pack to an arbitrary location. Prepare for this by adding a parameter which controls the destination of the cruft pack.For now, provide "packtmp" so that this commit does not change any behavior.
Signed-off-by Taylor Blau <[email protected]>--- builtin/repack.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)builtin/repack.c +1
-0@@ -662,6 +662,7 @@ static int write_midx_included_packs(struct string_list *include, } static int write_cruft_pack(const struct pack_objects_args *args, + const char *destination, const char *pack_prefix, const char *cruft_expiration, struct string_list *names,
builtin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 678
Quoted 5 lines
builtin/repack.c +2
-0@@ -673,8 +674,10 @@ static int write_cruft_pack(const struct pack_objects_args *args,struct string_list_item *item;FILE *in, *out;int ret; +const char *scratch; +int local =skip_prefix (destination, packdir, &scratch);
Hmph. In an earlier step we got rid of the hardcoded assumption on where the packtmp is, and we are passing destination in (where the existing callers call us with packtmp) to make it even better, but we acquire the dependency on packdir global with this step. It's just a couple of file-scope static global variables, so it is not a huge deal.
Quoted 7 lines
builtin/repack.c +1
-1-prepare_pack_objects (&cmd, args, packtmp); +prepare_pack_objects (&cmd, args, destination);strvec_push (&cmd.args,"--cruft" );if (cruft_expiration)@@ -714,7 +717,12 @@ static int write_cruft_pack(const struct pack_objects_args *args,if (line.len != the_hash_algo->hexsz)
builtin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 726
Quoted 10 lines
builtin/repack.c +6
-1die (_ ("repack: Expecting full hex object ID lines only " "from pack-objects." )); -string_list_append (names, line.buf); +/* +* avoid putting packs written outside of the repository in the +* list of names +*/ +if (local) +string_list_append (names, line.buf); }
Even if we do not want to contaminate the "names" list with packs that are not in the repository, wouldn't our caller still want to be able to tell what packs they are?
What I am wondering is if it makes more sense to have the caller pass &names (which can be NULL to just discard the output from the pack-objects command) so that this function can concentrate on what it does (i.e. formulate the command to write cruft packs and then report the packs that are created), without having to worry about the management of the &names thing, which can be done by the caller of this function? We are already passing &names, so it may be the matter of caller deciding to pass &names or NULL based on the value of destination it passes to the function?
builtin/repack.c int cmd_repack(int argc, const char **argv, const char *prefix) · line 1000
Quoted 9 lines
builtin/repack.c +1
-1@@ -986,7 +994,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix) cruft_po_args.local = po_args.local; cruft_po_args.quiet = po_args.quiet; - ret =write_cruft_pack (&cruft_po_args, pack_prefix, + ret =write_cruft_pack (&cruft_po_args, packtmp, pack_prefix, cruft_expiration, &names, &existing_nonkept_packs, &existing_kept_packs);
For example, this callsite will always want to pass &names because it is always about local pack, right?
Thanks.
Re: [PATCH 3/4] builtin/repack.c: write cruft packs to arbitrary locations
Quoted 22 lines · Junio C Hamano
Quoted 7 lines
builtin/repack.c +1
-1-prepare_pack_objects (&cmd, args, packtmp); +prepare_pack_objects (&cmd, args, destination);strvec_push (&cmd.args,"--cruft" );if (cruft_expiration)@@ -714,7 +717,12 @@ static int write_cruft_pack(const struct pack_objects_args *args,if (line.len != the_hash_algo->hexsz)builtin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 726
Quoted 10 lines
builtin/repack.c +6
-1die (_ ("repack: Expecting full hex object ID lines only " "from pack-objects." )); -string_list_append (names, line.buf); +/* +* avoid putting packs written outside of the repository in the +* list of names +*/ +if (local) +string_list_append (names, line.buf); }Even if we do not want to contaminate the "names" list with packs that are not in the repository, wouldn't our caller still want to be able to tell what packs they are?
Quoted 9 lines
What I am wondering is if it makes more sense to have the caller pass &names (which can be NULL to just discard the output from the pack-objects command) so that this function can concentrate on what it does (i.e. formulate the command to write cruft packs and then report the packs that are created), without having to worry about the management of the &names thing, which can be done by the caller of this function? We are already passing &names, so it may be the matter of caller deciding to pass &names or NULL based on the value of destination it passes to the function?
It would be nice if it were possible to avoid passing names entirely here, but we still need it to determine the set of packs we already wrote a few lines above when we write the input to pack-objects --cruft.
Thanks,
Taylor
Re: [PATCH 3/4] builtin/repack.c: write cruft packs to arbitrary locations
In reply to Taylor Blaubuiltin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 720
Quoted 6 lines · Taylor Blau
builtin/repack.c +1
-1@@ -714,7 +717,12 @@ static int write_cruft_pack(const struct pack_objects_args *args,if (line.len != the_hash_algo->hexsz)die (_ ("repack: Expecting full hex object ID lines only " "from pack-objects." )); -string_list_append (names, line.buf); +/*
This line looked oddly out-of-alignment with the next one.
It seems that the comment is preceded by spaces and not tabs. Perhaps Junio fixed this during his application of the patch to keep the builds happy.
builtin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 725
Quoted 5 lines
builtin/repack.c +5
-0+* avoid putting packs written outside of the repository in the +* list of names +*/ +if (local) +string_list_append (names, line.buf);
LGTM.
Thanks,
-Stolee
Re: [PATCH 3/4] builtin/repack.c: write cruft packs to arbitrary locations
Quoted 10 lines · Derrick Stolee
builtin/repack.c static int write_cruft_pack(const struct pack_objects_args *args, · line 720
Quoted 6 lines · Taylor Blau
builtin/repack.c +1
-1@@ -714,7 +717,12 @@ static int write_cruft_pack(const struct pack_objects_args *args,if (line.len != the_hash_algo->hexsz)die (_ ("repack: Expecting full hex object ID lines only " "from pack-objects." )); -string_list_append (names, line.buf); +/* This line looked oddly out-of-alignment with the next one.
Quoted 3 lines
It seems that the comment is preceded by spaces and not tabs. Perhaps Junio fixed this during his application of the patch to keep the builds happy.
Odd. In my copy, which I got from gitster/git before Junio went offline, the alignment looks fine.
Thanks for double checking, though.
Thanks,
Taylor
PATCH 4/4 builtin/repack.c: implement `--expire-to` for storing pruned objects
In reply to Taylor BlauWhen pruning objects with --cruft, git repack offers some flexibility when selecting the set of which objects are pruned via the --cruft-expiration option.
This is useful for expiring objects which are older than the grace period, making races where to-be-pruned objects become reachable and then ancestors of freshly pushed objects, leaving the repository in a corrupt state after pruning substantially less likely [1].
But in practice, such races are impossible to avoid entirely, no matter how long the grace period is. To prevent this race, it is often advisable to temporarily put a repository into a read-only state. But in practice, this is not always practical, and so some middle ground would be nice.
This patch introduces a new option, --expire-to, which teaches git repack to write an additional cruft pack containing just the objects which were pruned from the repository. The caller can specify a directory outside of the current repository as the destination for this second cruft pack.
This makes it possible to prune objects from a repository, while still holding onto a supplemental copy of them outside of the original repository. Having this copy on-disk makes it substantially easier to recover objects when the aforementioned race is encountered.
--expire-to is implemented in a somewhat convoluted manner, which is to take advantage of the fact that the first time write_cruft_pack() is called, it adds the name of the cruft pack to the names string list. That means the second time we call write_cruft_pack(), objects in the previously-written cruft pack will be excluded.
As long as the caller ensures that no objects are expired during the second pass, this is sufficient to generate a cruft pack containing all objects which don't appear in any of the new packs written by git repack, including the cruft pack. In other words, all of the objects which are about to be pruned from the repository.
It is important to note that the destination in --expire-to does not necessarily need to be a Git repository (though it can be) Notably, the expired packs do not contain all ancestors of expired objects. So if the source repository contains something like:
<unreachable>
/
C1 --- C2
\
refs/heads/masterwhere C2 is unreachable, but has a parent (C1) which is reachable, and C2 would be pruned, then the expiry pack will contain only C2, not C1.
[1]: https://lore.kernel.org/git/[email protected]/
--- Documentation/git-repack.txt | 6 ++ builtin/repack.c | 40 ++++++++++++ t/t7700-repack.sh | 121 +++++++++++++++++++++++++++++++++++ 3 files changed, 167 insertions(+)
Documentation/git-repack.txt +6 -0
@@ -74,6 +74,12 @@ to the new separate pack will be written. immediately instead of waiting for the next `git gc` invocation. Only useful with `--cruft -d`. +--expire-to=<dir>:: + Write a cruft pack containing pruned objects (if any) to the + directory `<dir>`. This option is useful for keeping a copy of + any pruned objects in a separate directory as a backup. Only + useful with `--cruft -d`. + -l:: Pass the `--local` option to 'git pack-objects'. See linkgit:git-pack-objects[1].
builtin/repack.c +40 -0
@@ -702,6 +702,10 @@ static int write_cruft_pack(const struct pack_objects_args *args,* By the time it is read here, it contains only the pack(s) * that were just written, which is exactly the set of packs we * want to consider kept. +* +* If `--expire-to` is given, the double-use served by `names` +* ensures that the pack written to `--expire-to` excludes any +* objects contained in the cruft pack. */ in =xfdopen (cmd.in,"w" );for_each_string_list_item (item, names)
@@ -755,6 +759,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)int geometric_factor =0 ;int write_midx =0 ;const char *cruft_expiration =NULL ; +const char *expire_to =NULL ;struct option builtin_repack_options[] = { OPT_BIT('a', NULL, &pack_everything,
@@ -804,6 +809,8 @@ int cmd_repack(int argc, const char **argv, const char *prefix) N_("find a geometric progression with factor <N>")),OPT_BOOL ('m' ,"write-midx" , &write_midx,N_ ("write a multi-pack index of the resulting packs" )), +OPT_STRING (0 ,"expire-to" , &expire_to,N_ ("dir" ), +N_ ("pack prefix to store a pack containing pruned objects" )), OPT_END() };
@@ -1000,6 +1007,39 @@ int cmd_repack(int argc, const char **argv, const char *prefix) &existing_kept_packs);if (ret)return ret; + +if (delete_redundant && expire_to) { +/* +* If `--expire-to` is given with `-d`, it's possible +* that we're about to prune some objects. With cruft +* packs, pruning is implicit: any objects from existing +* packs that weren't picked up by new packs are removed +* when their packs are deleted. +* +* Generate an additional cruft pack, with one twist: +* `names` now includes the name of the cruft pack +* written in the previous step. So the contents of +* _this_ cruft pack exclude everything contained in the +* existing cruft pack (that is, all of the unreachable +* objects which are no older than +* `--cruft-expiration`). +* +* To make this work, cruft_expiration must become NULL +* so that this cruft pack doesn't actually prune any +* objects. If it were non-NULL, this call would always +* generate an empty pack (since every object not in the +* cruft pack generated above will have an mtime older +* than the expiration). +*/ + ret =write_cruft_pack (&cruft_po_args, expire_to, + pack_prefix, +NULL , + &names, + &existing_nonkept_packs, + &existing_kept_packs); +if (ret) +return ret; + } }string_list_sort (&names);
t/t7700-repack.sh +121 -0
125 lines not on this page · raw message
Signature · 1 line
2.38.0.16.g393fd4c6db
Re: [PATCH 4/4] builtin/repack.c: implement `--expire-to` for storing pruned objects
Quoted 3 lines · Taylor Blau
When pruning objects with
--cruft,git repackoffers some flexibility when selecting the set of which objects are pruned via the--cruft-expirationoption.
This patch looks good.
Creating these cruft packs in the expire directory does help remove the main problem of the race condition. This currently requires some external system to check that no races happened and it is safe to delete the pack in the expire directory. Also, that external tool is needed to move that expired pack (or preferably, only the necessary objects) back into the repository.
Some future series could find a way to handle those situations, perhaps within 'git fsck' to pull missing reachable objects from the expire directory. Definitely not required for this series, though.
Thanks,
-Stolee
Re: [PATCH 4/4] builtin/repack.c: implement `--expire-to` for storing pruned objects
Quoted 15 lines · Derrick Stolee
Quoted 3 lines · Taylor Blau
When pruning objects with
--cruft,git repackoffers some flexibility when selecting the set of which objects are pruned via the--cruft-expirationoption.This patch looks good.
Creating these cruft packs in the expire directory does help remove the main problem of the race condition. This currently requires some external system to check that no races happened and it is safe to delete the pack in the expire directory. Also, that external tool is needed to move that expired pack (or preferably, only the necessary objects) back into the repository.
Quoted 4 lines
Some future series could find a way to handle those situations, perhaps within 'git fsck' to pull missing reachable objects from the expire directory. Definitely not required for this series, though.
Thanks. Let's start merging this one down.
Thanks,
Taylor