Jeff King <peff@xxxxxxxx> writes: > On Tue, Aug 25, 2020 at 03:45:52PM -0700, Junio C Hamano wrote: > >> The subcommand is unusably slow and the reason why nobody reports it >> as a performance bug is suspected to be the absense of users. Let's >> show a big message that asks the user to tell us that they still >> care about the command when an attempt is made to run the command, >> with an escape hatch to override it with a command line option. > > I was looking at the history here and noticed this topic, which I > somehow missed when it happened: > > $ git show -s cf0879f7e98d2213503622f780d2ab0dd3f93477 > commit cf0879f7e98d2213503622f780d2ab0dd3f93477 > Merge: 3710f60a80 0e37abd2e8 > Author: Junio C Hamano <gitster@xxxxxxxxx> > Date: Thu Mar 7 09:59:54 2019 +0900 > > Merge branch 'sc/pack-redundant' > > Update the implementation of pack-redundant for performance in a > repository with many packfiles. > > * sc/pack-redundant: > pack-redundant: consistent sort method > pack-redundant: rename pack_list.all_objects > pack-redundant: new algorithm to find min packs > pack-redundant: delete redundant code > pack-redundant: delay creation of unique_objects > t5323: test cases for git-pack-redundant > > So it sounds like: > > - somebody does care enough to use it > > - it may not be horrifically slow anymore > > So it may not be worth trying to follow through on the deprecation > (though the fact that neither of us realized this makes me worried for > the general state of maintenance of this code). OK. Just dropping the topic is the easiest ;-) Thanks.
