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;
next prev parent 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).