On Wed, Aug 26, 2015 at 4:02 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley <philipoakley@xxxxxxx> wrote: >> From: "Jacob Keller" <jacob.keller@xxxxxxxxx> >>> >>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano <gitster@xxxxxxxxx> >>> wrote: >>>> >>>> But notice that I said "if you really want to". I personally think >>>> it is a road to madness. >>> >>> >>> Agreed. I don't believe in command line API here. I think we'd need a >>> better solution. >>> >>> My gut says: Live with the warts on old commands and try to make >>> people use command words for new commands. >>> -- >> >> Agreed. However Graeme's original question also said "I can supply a more >> extensive list if needed", and "I still have to reference the help to remind >> me of what parameter to use in certain situation", which suggests that one >> option is to capture that list within some part of the documentation, >> especially if Graeme already has an easy to read layout. >> >> If it could be part of the documenation, where should it go - gitcli or >> perhaps it's own guide (`git help -g` and friends)? >> > > I hope to spend some time investigating this in the near future. > Personally I feel that command names make more sense than options > since they are essentially non-options, and it helps separate > logically related but non-equivalent operations more easily. > > The confusion that results from git-checkout, and git-branch has > caught more than a few new people at $dayjob. > > Regards, > Jake That being said, use of "--create" or so forth really isn't that bothersome so maybe the gains outway the cons here. Regards, Jake -- 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