Re: git show and the --quiet option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2011-05-30 at 11:32 +0200, Carlos MartÃn Nieto wrote:
> On Sat, May 28, 2011 at 12:17:40PM -0700, Junio C Hamano wrote:
> > Carlos MartÃn Nieto <cmn@xxxxxxxx> writes:
> > 

> > How does this patch look?
> > 
> > It does not fix "git show master~10 master^..master", but instead of just
> > hijacking and ignoring the --quiet option like your patch did, it actually
> > flips the option the user wanted to affect from the command line.
> 
> It's fine if that's what we want to do. The reason I blocked --quiet
> instead of converting it to -s is because it seemed less surprising
> than passing --quiet and still getting output (if I pass --quiet, I'd
> expect the application to really be quiet), which doesn't happen in
> the commands that accept --quiet on purpose. Then again, the log
> family doesn't make any sense without any output, so if you argue that
> way, --quiet means "quieter", which makes the interface less
> consistent, but I don't feel that strongly about it

There's a lot of stuff out there for which --quiet does not imply
--silent. I side with Junio on the solution.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]