Re: [PATCH 4/6] pack-objects: stop respecting pack.writebitmaps

Jeff King [off-list ref] 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.

On Tue, Jun 10, 2014 at 02:07:37PM -0700, Junio C Hamano wrote:

quoted

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.

That is my gut, too (and why I posted the patch). I was mostly just
trying to make sure it was not me being lazy (it is easy to be so when
you are the one writing the patches, rather than the one reviewing
them or acting as maintainer). :)

-Peff