Re: [PATCH] rev-{list,parse}: allow -<n> as shorthand for --max-count=<n>

From: Eric Wong <normalperson@yhbt.net>
Date: Jan 25, 2006, 06:33 UTC
Message-ID: <20060125063325.GA7953@mail.yhbt.net>
In-Reply-To: <7vd5iicauh.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 10 quoted lines

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Some versions of head(1) and tail(1) allow their line limits to be
> > parsed this way.  I find --max-count to be a commonly used option,
> > and also similar in spirit to head/tail, so I decided to make life
> > easier on my worn out (and lazy :) fingers with this patch.
> 
> As an old timer, I personally am very used to "head -4", but
> also have been training my fingers to say "head -n 4" for the
> past few years, because the former is not POSIXly correct.

I don't agree with POSIX on this point, and I don't see why git should be bound to POSIX, especially at the UI level just because it's POSIX.

Fwiw, head/tail in coreutils distributed by Debian still supports -<n> alongside -n <n> and -n<n>.

> At the same time, I agree that --max-count *was* a mistake.  We
> should maybe say "-n <n>" perhaps?

Then, -n<n> (w/o the space) should be supported as well. Heck, I've been wanting GNU getopt_long() option parsing in git for a while. Not sure if I'll have time to implement it myself any time soon, though.

-- 
Eric Wong