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

Jeff King <peff@peff.net> writes:

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

> [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 17:15 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
2015-06-24 17:15       ` Junio C Hamano [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqvbed9gf7.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).