git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [RFC/PATCH] pack-redundant: escalate deprecation warning to an error
@ 2023-03-23 20:40 Jeff King
  2023-03-23 20:56 ` Junio C Hamano
  0 siblings, 1 reply; 5+ messages in thread
From: Jeff King @ 2023-03-23 20:40 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

In c3b58472be2 (pack-redundant: gauge the usage before proposing its
removal, 2020-08-25), we added a big, ugly warning when pack-redundant
is run. The plan there indicated that we would ratchet that up to an
error before finally removing it. Since it has been 2.5 years (and 9
releases) since then, let's continue with the plan.

Note that we did get one bite on the warning, which was somebody asking
about alternatives:

  https://lore.kernel.org/git/CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com/

but we didn't undo the ugly warning (and the advice continues to be "use
repack -d" instead).

There was also some discussion around the time of the deprecation that
pack-redundant was invoked by the bitbake tool, and it still seems to do
so now:

  https://git.openembedded.org/bitbake

That use should probably just go away in favor of an occasional repack
(which probably even happens via auto-gc after fetch these days).

But since neither of those data points caused us to cancel the
deprecation plan by dropping the warning, it seems like we should
proceed with the next step.

Signed-off-by: Jeff King <peff@peff.net>
---
I was looking in this file recently, and was reminded of the deprecation
plan. The two data points above do give me a little bit of pause, but it
seems like the current state is the worst of both worlds: we do not have
the benefit of dropping the code, and people who try to use the command
have a bad experience. So we should probably either proceed (as with
this patch), or decide we need to keep pack-redundant.

 builtin/pack-redundant.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c
index 82115c5808c..5e93d873208 100644
--- a/builtin/pack-redundant.c
+++ b/builtin/pack-redundant.c
@@ -604,6 +604,7 @@ int cmd_pack_redundant(int argc, const char **argv, const char *prefix)
 			"option, '--i-still-use-this', on the command line\n"
 			"and let us know you still use it by sending an e-mail\n"
 			"to <git@vger.kernel.org>.  Thanks.\n"), stderr);
+		die(_("refusing to run without --i-still-use-this"));
 	}
 
 	if (load_all_packs)
-- 
2.40.0.597.ge37e901cd8f

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [RFC/PATCH] pack-redundant: escalate deprecation warning to an error
  2023-03-23 20:40 [RFC/PATCH] pack-redundant: escalate deprecation warning to an error Jeff King
@ 2023-03-23 20:56 ` Junio C Hamano
  2023-03-23 21:16   ` Taylor Blau
  0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2023-03-23 20:56 UTC (permalink / raw)
  To: Jeff King; +Cc: git

Jeff King <peff@peff.net> writes:

> I was looking in this file recently, and was reminded of the deprecation
> plan. The two data points above do give me a little bit of pause, but it
> seems like the current state is the worst of both worlds: we do not have
> the benefit of dropping the code, and people who try to use the command
> have a bad experience. So we should probably either proceed (as with
> this patch), or decide we need to keep pack-redundant.

Sounds like a good thing to do.  Will queue.  Thanks.

>
>  builtin/pack-redundant.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c
> index 82115c5808c..5e93d873208 100644
> --- a/builtin/pack-redundant.c
> +++ b/builtin/pack-redundant.c
> @@ -604,6 +604,7 @@ int cmd_pack_redundant(int argc, const char **argv, const char *prefix)
>  			"option, '--i-still-use-this', on the command line\n"
>  			"and let us know you still use it by sending an e-mail\n"
>  			"to <git@vger.kernel.org>.  Thanks.\n"), stderr);
> +		die(_("refusing to run without --i-still-use-this"));
>  	}
>  
>  	if (load_all_packs)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC/PATCH] pack-redundant: escalate deprecation warning to an error
  2023-03-23 20:56 ` Junio C Hamano
@ 2023-03-23 21:16   ` Taylor Blau
  2023-03-23 21:23     ` Junio C Hamano
  0 siblings, 1 reply; 5+ messages in thread
From: Taylor Blau @ 2023-03-23 21:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, git

On Thu, Mar 23, 2023 at 01:56:26PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I was looking in this file recently, and was reminded of the deprecation
> > plan. The two data points above do give me a little bit of pause, but it
> > seems like the current state is the worst of both worlds: we do not have
> > the benefit of dropping the code, and people who try to use the command
> > have a bad experience. So we should probably either proceed (as with
> > this patch), or decide we need to keep pack-redundant.
>
> Sounds like a good thing to do.  Will queue.  Thanks.

Yeah, I agree with and am persuaded by the "worst of both worlds"
argument. I think that changing this to a die() is sensible for now.

At what point would it be fair to drop this builtin entirely from the
tree?

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC/PATCH] pack-redundant: escalate deprecation warning to an error
  2023-03-23 21:16   ` Taylor Blau
@ 2023-03-23 21:23     ` Junio C Hamano
  2023-03-28 19:06       ` [PATCH] pack-redundant: document deprecation Jeff King
  0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2023-03-23 21:23 UTC (permalink / raw)
  To: Taylor Blau; +Cc: Jeff King, git

Taylor Blau <me@ttaylorr.com> writes:

> On Thu, Mar 23, 2023 at 01:56:26PM -0700, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>> > I was looking in this file recently, and was reminded of the deprecation
>> > plan. The two data points above do give me a little bit of pause, but it
>> > seems like the current state is the worst of both worlds: we do not have
>> > the benefit of dropping the code, and people who try to use the command
>> > have a bad experience. So we should probably either proceed (as with
>> > this patch), or decide we need to keep pack-redundant.
>>
>> Sounds like a good thing to do.  Will queue.  Thanks.
>
> Yeah, I agree with and am persuaded by the "worst of both worlds"
> argument. I think that changing this to a die() is sensible for now.
>
> At what point would it be fair to drop this builtin entirely from the
> tree?

I notice that "git pack-redundant --help" does not say anything
about its deprecation.  We probably should add one together with
the patch in question, and then consider that the count-down timer
has finally started.

The timer should last probably for at least a few cycles.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH] pack-redundant: document deprecation
  2023-03-23 21:23     ` Junio C Hamano
@ 2023-03-28 19:06       ` Jeff King
  0 siblings, 0 replies; 5+ messages in thread
From: Jeff King @ 2023-03-28 19:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Taylor Blau, git

On Thu, Mar 23, 2023 at 02:23:46PM -0700, Junio C Hamano wrote:

> I notice that "git pack-redundant --help" does not say anything
> about its deprecation.  We probably should add one together with
> the patch in question, and then consider that the count-down timer
> has finally started.

Good thinking. Here is a patch.

-- >8 --
Subject: [PATCH] pack-redundant: document deprecation

Running the command itself has generated a warning for several versions,
which has recently been upgraded to an error. Let's also make sure the
documentation mentions what is going on. This also gives us a good spot
to explain the reasoning and recommend alternatives.

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/git-pack-redundant.txt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
index 99ef13839d4..13c3eb5ec96 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -11,6 +11,20 @@ SYNOPSIS
 [verse]
 'git pack-redundant' [--verbose] [--alt-odb] (--all | <pack-filename>...)
 
+WARNING
+-------
+`git pack-redundant` has been deprecated and is scheduled for removal in
+a future version of Git. Because it can only remove entire duplicate
+packs and not individual duplicate objects, it is generally not a useful
+tool for reducing repository size. You are better off using `git gc` to
+do so, which will put objects into a new pack, removing duplicates.
+
+Running `pack-redundant` without the `--i-still-use-this` flag will fail
+in this release. If you believe you have a use case for which
+`pack-redundant` is better suited and oppose this removal, please
+contact the Git mailing list at git@vger.kernel.org. More information
+about the list is available at https://git-scm.com/community.
+
 DESCRIPTION
 -----------
 This program computes which packs in your repository
-- 
2.40.0.616.gf524ec75088


^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-03-28 19:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-23 20:40 [RFC/PATCH] pack-redundant: escalate deprecation warning to an error Jeff King
2023-03-23 20:56 ` Junio C Hamano
2023-03-23 21:16   ` Taylor Blau
2023-03-23 21:23     ` Junio C Hamano
2023-03-28 19:06       ` [PATCH] pack-redundant: document deprecation Jeff King

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