On Mon, 1 Feb 2010, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > > > Grrrrr. This is a terrible discrepency given that all the other > > arguments in Git are always byte based, with the optional k/m/g suffix, > > by using git_parse_ulong(). So IMHO I'd just change --max-pack-size to > > be in line with all the rest and have it accept bytes instead of MB. > > And of course I'd push such a change to be included in v1.7.0 along with > > the other incompatible fixes. > > All of the "other incompatible" changes had ample leading time for > transition with warnings and all. > > I am afraid that doing this "unit change" is way too late for 1.7.0, and > it makes me somewhat unhappy to hear such a suggestion. It belittles all > the careful planning that has been done for these other changes to help > protect the users from transition pain. > > Introduce --max-pack-megabytes that is a synonym for --max-pack-size for > now, and warn when --max-pack-size is used; warn that --max-pack-size will > count in bytes in 1.8.0. Ship 1.7.0 with that change. --max-pack-bytes > can also be added if you feel like, while at it. > > But changing the unit --max-pack-size counts in to bytes in 1.7.0 feels > a bit too irresponsible for the existing users. Thing is... I don't know if the --max-pack-size argument is really that used. I'd expect people relying on that feature to use the config variable instead, given that 'git gc' has no idea about --max-pack-size anyway. People using the --max-pack-size argument directly are probably doing so only to experiment with it, and then setting the config variable, probably using the wrong unit. The fact that such a discrepancy just came to our attention after all the time this feature has existed is certainly a good indicator of its popularity. I understand the really unfortunate timing for such a change. OTOH there is a big advantage to bundle as much incompatibilities together at the same time, as people will be prepared for such things already. While I share your concern for advance warning and such, I think those concerns are worth an effort proportional to the depth of user exposure. Like for the THREADED_DELTA_SEARCH case, I'm wondering how much pain if at all might be saved with a transition plan vs the cost of maintaining that plan and carrying the discrepancy further. Nicolas -- 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