From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>, git <git@vger.kernel.org>
Subject: Re: [PATCH 4/6] pack-objects: stop respecting pack.writebitmaps
Date: Tue, 10 Jun 2014 14:07:37 -0700 [thread overview]
Message-ID: <xmqqoay08odi.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140610201913.GD14974@sigill.intra.peff.net> (Jeff King's message of "Tue, 10 Jun 2014 16:19:13 -0400")
Jeff King <peff@peff.net> writes:
> I'm not sure what we want to do with this. It _is_ a possible regression
> as explained above, but I really do find it improbable that anyone will
> care. Even at GitHub, where we use a custom script instead of running
> `git gc`, we hook into the repack code, and not directly into
> pack-objects.
>
> One option is obviously to drop it as not worth it (you don't see the
> benefit here, but it enables the cleanups in the rest of the series).
>
> Another option is noting that the regression is worth dealing with,
> adding a deprecation notice, and phasing it out eventually. I tend to
> think it's not worth the trouble here.
>
> Another option is to track it to graduate to master during the next
> cycle. I.e., decide that the possible regression isn't a big deal.
My gut feeling is that the last one is sufficient. These low level
subcommands that are designed to be used by scripts (aka plumbing)
shouldn't have configuration options in the first place, and users
shouldn't depend on them even if they were added by design mistake.
> The final option is to track it for maint, along with the earlier
> patches. The argument for that is:
>
> 1. It's not a regression worth caring about (i.e., if it's not worth
> caring about for master, it's probably not worth caring about for
> maint, either).
>
> 2. It shortens the window in which the old behavior is in a release,
> making it less likely for somebody to try depending on it.
Yeah, probably. But I am not sure if that is even needed.
next prev parent reply other threads:[~2014-06-10 21:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 8:21 Disk waste with packs and .keep files Matthieu Moy
2014-06-10 18:53 ` Jeff King
2014-06-10 19:48 ` Jeff King
2014-06-10 20:07 ` [PATCH 0/6] fix repack.packKeptObjects regression in v2.0 Jeff King
2014-06-10 20:08 ` [PATCH 1/6] repack: do not accidentally pack kept objects by default Jeff King
2014-06-11 6:32 ` Jeff King
2014-06-10 20:09 ` [PATCH 2/6] repack: respect pack.writebitmaps Jeff King
2014-06-10 20:10 ` [PATCH 3/6] repack: s/write_bitmap/&s/ in code Jeff King
2014-06-10 20:19 ` [PATCH 4/6] pack-objects: stop respecting pack.writebitmaps Jeff King
2014-06-10 21:07 ` Junio C Hamano [this message]
2014-06-10 21:29 ` Jeff King
2014-06-10 20:19 ` [PATCH 5/6] repack: simplify handling of --write-bitmap-index Jeff King
2014-06-10 20:20 ` [PATCH 6/6] repack: introduce repack.writeBitmaps config option Jeff King
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=xmqqoay08odi.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--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.
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).