From: A Large Angry SCM <gitzilla@gmail.com>
Date: Mon, 06 Mar 2006 06:21:40 GMT
Subject: Re: [PATCH] annotate: Support annotation of files on other revisions.
Message-ID: <440BD4F4.3060906@gmail.com>
In-Reply-To: <20060306055036.GB26820@spearce.org>

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?