Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html