Shawn Pearce wrote: > Ryan Anderson <ryan@michonline.com> wrote: >>A Large Angry SCM wrote: >> >>>Ryan Anderson wrote: >>>... >>> >>>>For annotate, the syntax I was using was: >>>> git annotate Makefile headname >>>> >>>>I'm not married to it, so please, send a patch to change it if you want >>>>(Please fix up the test case I'm sending in this patch, as well.) >>>> >>>Wouldn't >>> git annotate <headname> <filename(s?)> >>>be more consistent with other git commands? >>> >>Yes, but <headname> (really, a commitish) needs to be optional. >> >>I should probably switch to: >> git annotate [-c|--commit <committish>] <filename> >>but that's partly why I'm asking for feedback. That works. Or maybe: git-annotate [<committish> --] <filename(s?)> or: git-annotate [<committish>] -- <filename(s?)> > > Yes but doesn't git-diff accept: > > git-diff Makefile > git-diff HEAD Makefile > > ? (Which is rather ugly as what if you have a tracked file actually > called HEAD and you want the first form when the commit-ish is > omitted.) So accepting an optional commit-ish before the filename > would be in line with what git-diff accepts today. > > But maybe breaking convention from git-diff now is a good thing, > with a future change to cleanup git-diff. > Looking at the documentation, it looks like all of the commands that take paths do so as the last arguments. With any commit/tree arguments being, either, required or flagged. Is there any reason that git-{annotate,blame} can't take more than one filename, ever? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Mon Mar 06 17:22:17 2006
This archive was generated by hypermail 2.1.8 : 2006-03-06 17:22:29 EST