On Thu, Jul 31, 2008 at 09:01:46AM +0000, Pierre Habouzit wrote:
quoted text
> On Thu, Jul 31, 2008 at 08:35:33AM +0000, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> >=20
> > > On Thu, Jul 31, 2008 at 12:36:59AM -0700, Junio C Hamano wrote:
> > >
> > >> Alas, shortlog does not take --all.  Yes, I know
> > >>=20
> > >> 	git log --since=3D3.day --all | git shortlog | sort | uniq -c
> > >>=20
> > >> is an obvious workaround, but it is mildly irritating.
> > >
> > > Hmm. Could it be as simple as:
> > >
> > > diff --git a/revision.c b/revision.c
> > > index a843c42..eaa5572 100644
> > > --- a/revision.c
> > > +++ b/revision.c
> > > @@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info =
*revs, int argc, const char **arg
quoted text
> > >  	    !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
> > >  	{
> > >  		unkv[(*unkc)++] =3D arg;
> > > -		return 0;
> > > +		return 1;
> > >  	}
> > > =20
> > >  	if (!prefixcmp(arg, "--max-count=3D")) {
> > >
> > > That is, handle_revision_opt says "yes we parsed this, and it should =
be
quoted text
> > > gone" even though it still gets stuck in the "unknown" section to be
> > > parsed by setup_revisions later.
>=20
>   Ack this is a correct fix. I wonder how this even works with other
> commands that use --all and stuff like that.

Oh actually I know: the parse_revision_opt machinery (that is buggy
because of this 0 result) is used in git-blame where --all is
meaningless anyways, and ... git-shortlog only. The legacy way to parse
revision options does not treats `0' answers differently from `1'
actually, I wonder why, because this is probably wrong.

This was a regression, I suppose prior to its parse-optification
git-shortlog accepted --all (and I see no valid reason for it not to).

Thanks a lot to Jeff for the good catch.

--=20
=C2=B7O=C2=B7  Pierre Habouzit
=C2=B7=C2=B7O                                                madcoder@debia=
n.org
OOO                                                http://www.madism.org