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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 23, 2015 at 02:05:28PM -0700, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> >  This extension does not change git's behavior at all. It is useful only
> >  for testing format-1 compatibility.
> > +
> > +`preciousObjects`
> > +~~~~~~~~~~~~~~~~~
> > +
> > +When the config key `extensions.preciousObjects` is set to `true`,
> > +objects in the repository MUST NOT be deleted (e.g., by `git-prune` or
> > +`git repack -d`).
> 
> OK.  In essense, the 'extension' on the disk is like 'capability' on
> the wire, in that you are not supposed to ask for capability they do
> not understand, and you are not supposed to touch a repository you
> do not understand.

Yeah, I think that is a good analogy.

> > +	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. They either run `git gc`, or they probably do
something more exotic and disable the safety check during that run[1].

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`.

-Peff

[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;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]