W dniu 2015-06-19 o 20:39, Junio C Hamano pisze: > Junio C Hamano <gits...@pobox.com> writes: > >> Except for the minor nits above, I think this is a good change. > > Oh, I forgot to mention one thing. I am not sure if this should be > called ULONG. "unsigned long"-ness is not the most important part > of this thing from the end-user's point of view, and also from the > point of view of the programmer who supports end-users by using this > new feature. > > It is "unlike OPT_INTEGER, the user can specify it as a human > readble scaled quantity" that is the reason to use this new thing. > I think we discussed to introduce OPT_HUMINT (HUM stands for HUMAN, > obviously) or some name like that a few years ago to do exactly > this, but that is not a great name, either.
On the output side it is often called --human-readable (e.g. du(1)), I don't know how it is called on input side (e.g. in 'dd' and friends). > I was tempted to suggest a name that has "size" in it, but because > places that we may conceivably want to use it in the future would be > to specify: > > - sizes, e.g. "split the packfiles into 4.3G chunks". > > - counts, e.g. "show me the most recent 2k commits". > > - bandwidth, e.g. "limit the transfer to consume at most 2M bps". > > which is not limited to size, it is not a very good idea, either. > > OPT_SCALED_ULONG(), or something with "scaled" in its name, perhaps? OPT_HUMAN_READABLE_INTEGER() is probably out as too long? ;-P -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in
