git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] introduce "preciousObjects" repository extension
Date: Wed, 24 Jun 2015 03:50:20 -0400	[thread overview]
Message-ID: <20150624075019.GA827@peff.net> (raw)
In-Reply-To: <xmqq1th2cezr.fsf@gitster.dls.corp.google.com>

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

> Jeff King <peff@peff.net> 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;

  reply	other threads:[~2015-06-24  7:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 10:50 [RFC/PATCH 0/2] bumping repository format version Jeff King
2015-06-23 10:53 ` [PATCH 1/2] introduce "extensions" form of core.repositoryformatversion Jeff King
2015-06-23 10:54 ` [PATCH 2/2] introduce "preciousObjects" repository extension Jeff King
2015-06-23 11:14   ` Duy Nguyen
2015-06-23 11:47     ` Jeff King
2015-06-23 21:05   ` Junio C Hamano
2015-06-24  7:50     ` Jeff King [this message]
2015-06-24 17:15       ` Junio C Hamano
2015-06-25 10:07         ` Jeff King
2015-06-23 21:31   ` David Turner
2015-06-24  7:55     ` Jeff King
2015-06-24  8:12   ` Jeff King
2015-06-24 10:29     ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150624075019.GA827@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).