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

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Mar 6, 2006, 06:21 UTC
Message-ID: <440BD4F4.3060906@gmail.com>
In-Reply-To: <20060306055036.GB26820@spearce.org>

Shawn Pearce wrote:

Show 21 quoted lines

> 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?)>

Show 14 quoted lines

> 
> 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?