[PATCH] reset: add --quiet option

[PATCH] reset: add --quiet option

[Felipe Contreras]

There's already -q, but --quiet is missing.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-reset.txt |    1 +
 builtin-reset.c             |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2d27e40..9df6de2 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -62,6 +62,7 @@ This means that `git reset -p` is the opposite of `git add -p` (see
 linkgit:git-add[1]).
 
 -q::
+--quiet::
 	Be quiet, only report errors.
 
 <commit>::
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..c0127c4 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -209,7 +209,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 				"reset HEAD, index and working tree", HARD),
 		OPT_SET_INT(0, "merge", &reset_type,
 				"reset HEAD, index and working tree", MERGE),
-		OPT_BOOLEAN('q', NULL, &quiet,
+		OPT_BOOLEAN('q', "quiet", &quiet,
 				"disable showing new HEAD in hard reset and progress message"),
 		OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
 		OPT_END()
-- 
1.6.6.rc0.63.g0471c

Re: [PATCH] reset: add --quiet option

[Stephen Boyd]

On Sun, 2009-11-29 at 12:58 +0200, Felipe Contreras wrote:
> diff --git a/builtin-reset.c b/builtin-reset.c
> index 73e6022..c0127c4 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -209,7 +209,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>  				"reset HEAD, index and working tree", HARD),
>  		OPT_SET_INT(0, "merge", &reset_type,
>  				"reset HEAD, index and working tree", MERGE),
> -		OPT_BOOLEAN('q', NULL, &quiet,
> +		OPT_BOOLEAN('q', "quiet", &quiet,
>  				"disable showing new HEAD in hard reset and progress message"),
>  		OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
>  		OPT_END()

Why not just OPT__QUIET? We lose the specific help string but it's
possible that what quiet is silencing will change in the future.

Maybe you could move the help string to the documentation if you want to
save it.

Re: [PATCH] reset: add --quiet option

[Junio C Hamano]

Stephen Boyd <bebarino@gmail.com> writes:

> Why not just OPT__QUIET?

Good question. I was in no hurry to queue this, so Felipe has plenty time
to respond.

Re: [PATCH] reset: add --quiet option

[Felipe Contreras]

On Mon, Nov 30, 2009 at 3:18 AM, Stephen Boyd <bebarino@gmail.com> wrote:
> Why not just OPT__QUIET? We lose the specific help string but it's
> possible that what quiet is silencing will change in the future.

I thought somebody would complain about loosing that string. In any
case, first step is adding --query to 'git reset', second step is
moving all OPT_BOOLEAN('q' to OPT__QUIET; there are other commands
doing the same.

-- 
Felipe Contreras

Re: [PATCH] reset: add --quiet option

[Stephen Boyd]

On Mon, Nov 30, 2009 at 2:19 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I thought somebody would complain about loosing that string. In any
> case, first step is adding --query to 'git reset', second step is
> moving all OPT_BOOLEAN('q' to OPT__QUIET; there are other commands
> doing the same.
>

If you're already touching the line why not just do it once? I agree a
follow-up patch to cover the other commands would be good.

Re: [PATCH] reset: add --quiet option

[Felipe Contreras]

On Mon, Nov 30, 2009 at 11:45 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> If you're already touching the line why not just do it once? I agree a
> follow-up patch to cover the other commands would be good.

Because the less trivial the patches, the less luck I have of getting
them applied :)

Anyway, I sent a patch to use OPT__QUIET directly in two places.

-- 
Felipe Contreras

Re: [PATCH] reset: add --quiet option

[Stephen Boyd]

On Thu, 2009-12-03 at 11:33 +0200, Felipe Contreras wrote:
> On Mon, Nov 30, 2009 at 11:45 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> > If you're already touching the line why not just do it once? I agree a
> > follow-up patch to cover the other commands would be good.
> 
> Because the less trivial the patches, the less luck I have of getting
> them applied :)

Heh, still seems pretty trivial to me ;-)

> 
> Anyway, I sent a patch to use OPT__QUIET directly in two places.
> 

Great. Thanks for making it more consistent.

Re: [PATCH] reset: add --quiet option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Mon, Nov 30, 2009 at 11:45 PM, Stephen Boyd <bebarino@gmail.com> wrote:
>> If you're already touching the line why not just do it once? I agree a
>> follow-up patch to cover the other commands would be good.
>
> Because the less trivial the patches, the less luck I have of getting
> them applied :)

Well, the name of the game is not "let me have more commits under my name
in a well known project".  It is "let's work together to make the system
better without stepping on each other's toes and without introducing
unintended side effects".

I actually do not think it is the complexity that matters.  It largely
depends on what other patches are in flight that may have interactions,
and if the change is suitable for the phase of the cycle.

> Anyway, I sent a patch to use OPT__QUIET directly in two places.

Yeah, I saw it and queued it to 'pu'.  Thanks.

We _might_ want to think about doing something about the lossage of "long
messages" by this conversion, and we may end up updating OPT__QUIET() to
allow its users supply messages that are more suitable than the default
one, but I do not want to see such a change to parse-options before 1.6.6
happens on the 'master' branch, as I do not have infinite mental
bandwidth.

Re: [PATCH] reset: add --quiet option

[Felipe Contreras]

On Fri, Dec 4, 2009 at 3:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Because the less trivial the patches, the less luck I have of getting
>> them applied :)
>
> Well, the name of the game is not "let me have more commits under my name
> in a well known project".  It is "let's work together to make the system
> better without stepping on each other's toes and without introducing
> unintended side effects".

Except that different people have different opinions about what's
"better", when it's OK to step on somebody else's toes,  and what's an
important side-effect.

> I actually do not think it is the complexity that matters.  It largely
> depends on what other patches are in flight that may have interactions,
> and if the change is suitable for the phase of the cycle.

And whether or not you consider the change desirable at all.

-- 
Felipe Contreras