Shawn Pearce wrote:
Ryan Anderson <ryan@xxxxxxxxxxxxxx> 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?
-
: 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