Re: [PATCH 2/2] introduce "preciousObjects" repository extension

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 2/2] introduce "preciousObjects" repository extension

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:05:29

Jeff King [off-list ref] writes:
quoted
quoted
+	if (delete_redundant && repository_format_precious_objects)
+		die("cannot repack in a precious-objects repo");
This message initially threw me off during my cursory reading, but
the code tells me that this is only about "repack -d".

Unfortunately the users do not get the chance to read the code;
perhaps s/cannot repack/& -d/; or something?
I agree that would be better. I originally just blocked all use of
git-repack, but at the last minute softened it to just "repack -d". I'm
not sure if that would actually help anyone in practice. Sure, doing
"git repack" without any options is not destructive, but I wonder if
anybody actually does it.
Hmph, if you cannot afford to lose objects that are unreachable from
your refs (because you know your repository has borrowers) but are
suffering from too many packs, wouldn't "repack -a" be the most
natural thing to do?  Maybe I am biased, but "git gc" is not the
first thing that comes to my mind in that situation.
So I think we could squash in the patch below (which also marks the
strings for translation). But I'd also be OK with the rule covering all
of `git repack`.
OK, will squash it in.
quoted hunk
[1] One of my proposed uses for this is to revamp the way we handle
    shared objects on GitHub servers. Right now objects get pushed to
    individual forks, and then migrate to a shared repository that is
    accessed via the alternates mechanism. I would like to move to
    symlinking the `objects/` directory to write directly into the
    shared space. But the destruction from accidentally running
    something like `git gc` in a fork is very high. With this patch, we
    can bump the forks to the v1 format and mark their objects as
    precious.

---
diff --git a/builtin/prune.c b/builtin/prune.c
index fc0c8e8..6a58e75 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -219,7 +219,7 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
 	}
 
 	if (repository_format_precious_objects)
-		die("cannot prune in a precious-objects repo");
+		die(_("cannot prune in a precious-objects repo"));
 
 	while (argc--) {
 		unsigned char sha1[20];
diff --git a/builtin/repack.c b/builtin/repack.c
index 8ae7fe5..3beda2c 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -194,7 +194,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
 				git_repack_usage, 0);
 
 	if (delete_redundant && repository_format_precious_objects)
-		die("cannot repack in a precious-objects repo");
+		die(_("cannot delete packs in a precious-objects repo"));
 
 	if (pack_kept_objects < 0)
 		pack_kept_objects = write_bitmaps;

Re: [PATCH 2/2] introduce "preciousObjects" repository extension

From: Jeff King <hidden>
Date: 2016-06-15 23:05:31

On Wed, Jun 24, 2015 at 10:15:08AM -0700, Junio C Hamano wrote:
quoted
I agree that would be better. I originally just blocked all use of
git-repack, but at the last minute softened it to just "repack -d". I'm
not sure if that would actually help anyone in practice. Sure, doing
"git repack" without any options is not destructive, but I wonder if
anybody actually does it.
Hmph, if you cannot afford to lose objects that are unreachable from
your refs (because you know your repository has borrowers) but are
suffering from too many packs, wouldn't "repack -a" be the most
natural thing to do?  Maybe I am biased, but "git gc" is not the
first thing that comes to my mind in that situation.
My assumption was that people fall into one of two categories:

  - people who just run `git gc`

  - people who are doing something clever, and will use `git
    repack` to do a full repack after making sure it is safe to do so.

    E.g., after "clone -s", it might be OK to do:

      for i in ../*.git; do
        git fetch $i +refs/*:refs/remotes/$i/*
      done
      git -c extensions.preciousObjects=false repack -ad

    But only the user can make that decision; git does not know whether
    "../*.git" is the complete set of children.

Certainly "git repack -a" is a safe stopgap in the shared-object parent,
but eventually you will want to do the clever thing. :)

I think it is OK to use this patch as a starting point, and for people
to loosen the rules later if there is a combination of repack flags that
are safe to run but not covered by the current logic (there is no
regression, since preciousObjects is a new extension, and going forward
it is OK to allow new safe things to open up workflows, but not the
other way around).

It may even be that the current patch even allows any sane workflow; I
am only claiming that I did not think too hard on it, and tried to err
on the side of safety, and allowing the workflow above.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help