Subject: Re: [PATCH] annotate: Support annotation of files on other revisions.

From: A Large Angry SCM <[email-masked]>
Date: Sun, 05 Mar 2006 22:21:40 -0800

Shawn Pearce wrote:
> Ryan Anderson <[email-masked]> 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?