On Fri, Nov 02, 2007 at 06:21:17PM +0000, Johannes Schindelin wrote: > Hi, > > On Fri, 2 Nov 2007, Pierre Habouzit wrote: > > > On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote: > > > > > That command [rev-parse] 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. > > Yeah, rev-parse's only purpose in life is to help scripts. (Even if it is > used sometimes -- even by myself -- to turn symbolic names into SHA-1s.) > > IMHO it makes tons of sense to put the functionality into that command, > even if it is not incremental. Okay so what do I do ? I create a new mode for git-rev-parse that does what I do in git-parseopt ? I can do that, I don't like it a lot, but if people it's better to work this way... It's also kind of counter intuitive to have git *rev-parse* doing that but oh well, after all it's plumbing -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpYPzlSHbmLq.pgp
Description: PGP signature
