On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote: > > > On Fri, 2 Nov 2007, Pierre Habouzit wrote: > > > On Fri, Nov 02, 2007 at 03:09:18PM +0000, Pierre Habouzit wrote: > > > This is also something that itches me, so here is a proposal for a > > > git-parseopt helper that can be used in shell scripts as an option > > > normalizer like getopt(1) does. > > > > > > I migrated the discussed git-clean.sh to use it as a proof of concept. > > > > Needless to say, this is fetchable from > > git://git.madism.org/git.git#ph/parseopt > > Hmm. Any reason why you didn't just extend on "git rev-parse"? Because I wasn't aware of the fact it was used to massage arguments of a function :) Though looking at the code git-rev-parse looks quite complicated and does not works the proper way: It show()s the arguments along the way, whereas you definitely need to parse them first if you end up spitting out the usage. I could of course plumb it as a new "mode" of git-rev-parse, but it sounds awkward. > That command was written exactly to parse a command line. This is really > cheesy, and doesn't really work right (it splits up numbers too), but you > get the idea.. I get the idea, though parse-options is not incremental at all, this could probably be done, but would complicate the API (we would need to allocate a state object e.g.). And parseoptions checks that options getting an argument have one, checks that options exists and so on. It looks like to me that it's not easy to plumb into rev-parse without being a brand new independant mode. We can do that, if we don't want yet-another-git-builtin/command, but in the spirit it'll remain a brand new "thing". Though I'd be glad to hear about what others think about it. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpb2mexIGyZJ.pgp
Description: PGP signature
