[PATCH] Implement rebase -q to fix pull --rebase -q

[PATCH] Implement rebase -q to fix pull --rebase -q

[Tuncer Ayaz]

This is needed on top of the fetch/pull -q/-v changes
to make
$ git pull --rebase -q
as quiet as expected.

Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
 git-pull.sh   |    2 +-
 git-rebase.sh |   31 +++++++++++++++++++++++--------
 2 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 1cac898..57fcee9 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -184,6 +184,6 @@ fi
 merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
 test true = "$rebase" &&
 	exec git-rebase $strategy_args --onto $merge_head \
-	${oldremoteref:-$merge_head}
+	$verbosity ${oldremoteref:-$merge_head}
 exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
 	"$merge_name" HEAD $merge_head $verbosity
diff --git a/git-rebase.sh b/git-rebase.sh
index 023a6dc..bbfdc2e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,7 +3,7 @@
 # Copyright (c) 2005 Junio C Hamano.
 #
 
-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'
+USAGE='[--interactive | -i] [-q] [-v] [--onto <newbase>] <upstream> [<branch>]'
 LONG_USAGE='git-rebase replaces <branch> with a new branch of the
 same name.  When the --onto option is provided the new branch starts
 out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
@@ -45,7 +45,7 @@ strategy=recursive
 do_merge=
 dotest="$GIT_DIR"/rebase-merge
 prec=4
-verbose=
+verbosity=1
 git_am_opt=
 
 continue_merge () {
@@ -135,7 +135,10 @@ move_to_original_branch () {
 finish_rb_merge () {
 	move_to_original_branch
 	rm -r "$dotest"
-	echo "All done."
+	if test $verbosity -gt 0
+	then
+		echo "All done."
+	fi
 }
 
 is_interactive () {
@@ -288,8 +291,11 @@ do
 		esac
 		do_merge=t
 		;;
+	-q|--quiet)
+		verbosity=0
+		;;
 	-v|--verbose)
-		verbose=t
+		verbosity=2
 		;;
 	--whitespace=*)
 		git_am_opt="$git_am_opt $1"
@@ -401,11 +407,14 @@ if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
 then
 	# Lazily switch to the target branch if needed...
 	test -z "$switch_to" || git checkout "$switch_to"
-	echo >&2 "Current branch $branch_name is up to date."
+	if test $verbosity -gt 0
+	then
+		echo >&2 "Current branch $branch_name is up to date."
+	fi
 	exit 0
 fi
 
-if test -n "$verbose"
+if test $verbosity -gt 1
 then
 	echo "Changes from $mb to $onto:"
 	# We want color (if set), but no pager
@@ -413,7 +422,10 @@ then
 fi
 
 # Detach HEAD and reset the tree
-echo "First, rewinding head to replay your work on top of it..."
+if test $verbosity -gt 0
+then
+	echo "First, rewinding head to replay your work on top of it..."
+fi
 git checkout -q "$onto^0" || die "could not detach HEAD"
 git update-ref ORIG_HEAD $branch
 
@@ -421,7 +433,10 @@ git update-ref ORIG_HEAD $branch
 # we just fast forwarded.
 if test "$mb" = "$branch"
 then
-	echo >&2 "Fast-forwarded $branch_name to $onto_name."
+	if test $verbosity -gt 0
+	then
+		echo >&2 "Fast-forwarded $branch_name to $onto_name."
+	fi
 	move_to_original_branch
 	exit 0
 fi
-- 
1.6.0.2.GIT

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Tuncer Ayaz]

On Wed, Dec 3, 2008 at 5:06 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> This is needed on top of the fetch/pull -q/-v changes
> to make
> $ git pull --rebase -q
> as quiet as expected.
>
> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
> ---
>  git-pull.sh   |    2 +-
>  git-rebase.sh |   31 +++++++++++++++++++++++--------
>  2 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 1cac898..57fcee9 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -184,6 +184,6 @@ fi
>  merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
>  test true = "$rebase" &&
>        exec git-rebase $strategy_args --onto $merge_head \
> -       ${oldremoteref:-$merge_head}
> +       $verbosity ${oldremoteref:-$merge_head}
>  exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
>        "$merge_name" HEAD $merge_head $verbosity
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 023a6dc..bbfdc2e 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -3,7 +3,7 @@
>  # Copyright (c) 2005 Junio C Hamano.
>  #
>
> -USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'
> +USAGE='[--interactive | -i] [-q] [-v] [--onto <newbase>] <upstream> [<branch>]'
>  LONG_USAGE='git-rebase replaces <branch> with a new branch of the
>  same name.  When the --onto option is provided the new branch starts
>  out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
> @@ -45,7 +45,7 @@ strategy=recursive
>  do_merge=
>  dotest="$GIT_DIR"/rebase-merge
>  prec=4
> -verbose=
> +verbosity=1
>  git_am_opt=
>
>  continue_merge () {
> @@ -135,7 +135,10 @@ move_to_original_branch () {
>  finish_rb_merge () {
>        move_to_original_branch
>        rm -r "$dotest"
> -       echo "All done."
> +       if test $verbosity -gt 0
> +       then
> +               echo "All done."
> +       fi
>  }
>
>  is_interactive () {
> @@ -288,8 +291,11 @@ do
>                esac
>                do_merge=t
>                ;;
> +       -q|--quiet)
> +               verbosity=0
> +               ;;
>        -v|--verbose)
> -               verbose=t
> +               verbosity=2
>                ;;
>        --whitespace=*)
>                git_am_opt="$git_am_opt $1"
> @@ -401,11 +407,14 @@ if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
>  then
>        # Lazily switch to the target branch if needed...
>        test -z "$switch_to" || git checkout "$switch_to"
> -       echo >&2 "Current branch $branch_name is up to date."
> +       if test $verbosity -gt 0
> +       then
> +               echo >&2 "Current branch $branch_name is up to date."
> +       fi

If anyone dislikes the additional three lines I could combine
the test with the action on one line. I'm just not sure that would
make it better, especially depending on log message length.

>        exit 0
>  fi
>
> -if test -n "$verbose"
> +if test $verbosity -gt 1
>  then
>        echo "Changes from $mb to $onto:"
>        # We want color (if set), but no pager
> @@ -413,7 +422,10 @@ then
>  fi
>
>  # Detach HEAD and reset the tree
> -echo "First, rewinding head to replay your work on top of it..."
> +if test $verbosity -gt 0
> +then
> +       echo "First, rewinding head to replay your work on top of it..."
> +fi
>  git checkout -q "$onto^0" || die "could not detach HEAD"
>  git update-ref ORIG_HEAD $branch
>
> @@ -421,7 +433,10 @@ git update-ref ORIG_HEAD $branch
>  # we just fast forwarded.
>  if test "$mb" = "$branch"
>  then
> -       echo >&2 "Fast-forwarded $branch_name to $onto_name."
> +       if test $verbosity -gt 0
> +       then
> +               echo >&2 "Fast-forwarded $branch_name to $onto_name."
> +       fi
>        move_to_original_branch
>        exit 0
>  fi
> --
> 1.6.0.2.GIT
>
>

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Junio C Hamano]

Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:

> This is needed on top of the fetch/pull -q/-v changes
> to make
> $ git pull --rebase -q
> as quiet as expected.

I am not sure if this is worth it, in the sense that it is not really
quiet enough (iow, it is not what I expect even though you claim "as
expected" here), and in another sense that making it really quiet may not
be what we want anyway.

How are you dealing with messages from the actual replaying of each local
commit on top of what is fetched?  In order to be able to tell where you
are when one of them fail in conflicts, you cannot stay silent while doing
so.

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Tuncer Ayaz]

On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> This is needed on top of the fetch/pull -q/-v changes
>> to make
>> $ git pull --rebase -q
>> as quiet as expected.
>
> I am not sure if this is worth it, in the sense that it is not really
> quiet enough (iow, it is not what I expect even though you claim "as

Junio, sorry for using 'expected'.
I thought about the wording while writing and had a feeling that 'expected'
may be too strong as it's my opinion only. I should have listened to myself :).

> expected" here), and in another sense that making it really quiet may not
> be what we want anyway.

I mainly use -q in automation where I only want output if something
goes wrong. Just like good old cp or mv do.
Do you think this is the wrong way to go?

> How are you dealing with messages from the actual replaying of each local
> commit on top of what is fetched?  In order to be able to tell where you
> are when one of them fail in conflicts, you cannot stay silent while doing
> so.

Fair point.

Log messages that are of importance to a failure should ideally be sent to
stderr but I think caching log messages for the failure case would
over-complicate
much of the code and is not worth it. Also you may not always know which part
of stdout messages are useful for the failure case and not getting the
same messages
on a rerun for many commands makes this hard to trace back, yeah.

As we've quietened pull/fetch/clone in a major already I am OK with leaving this
change out.
I'm definitely not advocating adding/changing anything when it's not clear we
want the changed behavior. It's easier to keep out than to remove it
later on :).

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Junio C Hamano]

"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:

> I mainly use -q in automation where I only want output if something
> goes wrong. Just like good old cp or mv do.
> Do you think this is the wrong way to go?
>
>> How are you dealing with messages from the actual replaying of each local
>> commit on top of what is fetched?  In order to be able to tell where you
>> are when one of them fail in conflicts, you cannot stay silent while doing
>> so.
>
> Fair point.

Ahh, ok, if this is for cron jobs, then it is understandable that:

 (1) You may want a successful "git pull" or "git pull --rebase" to be
     absolutely silent about what it did; and

 (2) A failed "git pull" and "git pull --rebase" that produces information
     other than the fact it failed would not help you, the receiver of a
     cron job report, very much.  You would go to the repository when it
     fails, reset the mess away, and then do the pull or pull-rebase
     yourself manually anyway.

If that is the motivation behind the series, I think you would really want
to squelch output from "format-patch | am -3" pipeline.

Another thing to consider is that, unlike simple single-operation commands
such as "mv" or "cp" you mentioned, what "git pull" does is much more
involved and has many different failure modes, so you cannot compare them
fairly.  Simple commands can have a single "quiet" level, but I have a
feeling that there is a difference between "quiet mode" I expect when I am
running "git pull" interactively and "quiet mode" I would want when I
would be driving "git pull" from a cron job.  IOW, you probably would want
something like "--really-quiet" mode.

I would write such a cron-job script to capture the log and send it only
upon failure from the underlying command if I were doing this myself,
though.

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Tuncer Ayaz]

On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> I mainly use -q in automation where I only want output if something
>> goes wrong. Just like good old cp or mv do.
>> Do you think this is the wrong way to go?
>>
>>> How are you dealing with messages from the actual replaying of each local
>>> commit on top of what is fetched?  In order to be able to tell where you
>>> are when one of them fail in conflicts, you cannot stay silent while doing
>>> so.
>>
>> Fair point.
>
> Ahh, ok, if this is for cron jobs, then it is understandable that:
>
>  (1) You may want a successful "git pull" or "git pull --rebase" to be
>     absolutely silent about what it did; and
>
>  (2) A failed "git pull" and "git pull --rebase" that produces information
>     other than the fact it failed would not help you, the receiver of a
>     cron job report, very much.  You would go to the repository when it
>     fails, reset the mess away, and then do the pull or pull-rebase
>     yourself manually anyway.
>
> If that is the motivation behind the series, I think you would really want
> to squelch output from "format-patch | am -3" pipeline.

You mean I should follow this path and produce a patch series instead?

> Another thing to consider is that, unlike simple single-operation commands
> such as "mv" or "cp" you mentioned, what "git pull" does is much more
> involved and has many different failure modes, so you cannot compare them
> fairly.  Simple commands can have a single "quiet" level, but I have a
> feeling that there is a difference between "quiet mode" I expect when I am
> running "git pull" interactively and "quiet mode" I would want when I

We have the same expectation here and IDE writers also seem to expect that.

> would be driving "git pull" from a cron job.  IOW, you probably would want
> something like "--really-quiet" mode.

Yeah, it gets messy and in the current codebase. I am also not sure whether
the effort/benefit ratio is good enough.

> I would write such a cron-job script to capture the log and send it only
> upon failure from the underlying command if I were doing this myself,
> though.

This is the way I do it now and I'm surprised I found no other simple way
than writing a wrapper script for it. At least not with vixie-cron.

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Junio C Hamano]

"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:

> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Ahh, ok, if this is for cron jobs, then it is understandable that:
>>
>>  (1) You may want a successful "git pull" or "git pull --rebase" to be
>>     absolutely silent about what it did; and
>>
>>  (2) A failed "git pull" and "git pull --rebase" that produces information
>>     other than the fact it failed would not help you, the receiver of a
>>     cron job report, very much.  You would go to the repository when it
>>     fails, reset the mess away, and then do the pull or pull-rebase
>>     yourself manually anyway.
>>
>> If that is the motivation behind the series, I think you would really want
>> to squelch output from "format-patch | am -3" pipeline.
>
> You mean I should follow this path and produce a patch series instead?

Not necessarily.  It is entirely up to you.

An important point at this point is that the patch as submitted, without
such a change, will not be useful to achieve the goal (1) above, because
it will still be chatty.

>> would be driving "git pull" from a cron job.  IOW, you probably would want
>> something like "--really-quiet" mode.
>
> Yeah, it gets messy and in the current codebase. I am also not sure whether
> the effort/benefit ratio is good enough.

I doubt "the current codebase" has more downside than upside as you seem
to imply.  The way rebase uses layered set of other commands keeps the
door open to spread the benefits around.  If you squelch format-patch, you
would help people who would want to drive it from their cron job (perhaps
they are on dial-up and they would rather batch things up than running
format-patch and send-email from their post-receive hook).  If you squelch
am, you would help people who use it as a part of their mailing list
scanning software that runs unattended.  Of course, you could choose to
squelch the "format-patch | am -3" pipeline in one go by redirecting the
entire pipe to somewhere, instead of giving individual commands --quiet
option.  If you did so, obviously the benefits won't be spread to users of
these underlying commands.

But I do not think squelching of these individual commands such as
format-patch, am, and pull are so useful in the larger picture in the
context of scripting; see below.

>> I would write such a cron-job script to capture the log and send it only
>> upon failure from the underlying command if I were doing this myself,
>> though.
>
> This is the way I do it now and I'm surprised I found no other simple way
> than writing a wrapper script for it. At least not with vixie-cron.

Actually I am not so surprised.

A cron job that contains a git pull most likely needs to be a script that
wants to do many other things anyway, such as chdir into the target
repository, make sure nobody (including yourself) did not by mistake went
into the repository and made local changes that may interfere with the
pull and if so abort, perform the pull, noticing its exit status, produce
the error report and exit if pull fails, validate each new commits the
pull brought in against some in-house coding standard, run a build test
(perhaps "make test") if pull succeeded, noticing its exit status, produce
the error report and exit if the build fails, install the build result if
build succeeded, and so on.  Individual steps such as "git pull" and "make
install" are only small self-contained building blocks in such a workflow,
and it is not unusual for such a script to redirect output from the
building blocks it uses and produce a summarized report at the very end of
the run using the redirected output, while emitting messages on its own.

In such an arrangement, having "a bit quieter than usual" option in the
underlying command, which would be what we would want for these primarily
interactive commands, is not very useful anyway, because the "quieter"
output mode may drop some information you might want to include in the
fuller report when something goes wrong, and filtering such "a bit
quieter" output takes as much effort as filtering the output from the
normal mode when there is nothing noteworthy to report and your script
wants to squelch the output entirely.

Re: [PATCH] Implement rebase -q to fix pull --rebase -q

[Tuncer Ayaz]

On Wed, Dec 3, 2008 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Ahh, ok, if this is for cron jobs, then it is understandable that:
>>>
>>>  (1) You may want a successful "git pull" or "git pull --rebase" to be
>>>     absolutely silent about what it did; and
>>>
>>>  (2) A failed "git pull" and "git pull --rebase" that produces information
>>>     other than the fact it failed would not help you, the receiver of a
>>>     cron job report, very much.  You would go to the repository when it
>>>     fails, reset the mess away, and then do the pull or pull-rebase
>>>     yourself manually anyway.
>>>
>>> If that is the motivation behind the series, I think you would really want
>>> to squelch output from "format-patch | am -3" pipeline.
>>
>> You mean I should follow this path and produce a patch series instead?
>
> Not necessarily.  It is entirely up to you.
>
> An important point at this point is that the patch as submitted, without
> such a change, will not be useful to achieve the goal (1) above, because
> it will still be chatty.

I personally don't see a huge point right now in implementing -q
in any more commands.

>>> would be driving "git pull" from a cron job.  IOW, you probably would want
>>> something like "--really-quiet" mode.
>>
>> Yeah, it gets messy and in the current codebase. I am also not sure whether
>> the effort/benefit ratio is good enough.
>
> I doubt "the current codebase" has more downside than upside as you seem
> to imply.  The way rebase uses layered set of other commands keeps the

I think it gets "messy" if you start implementing more and more
log levels without an internal consistent logging API. That's
all I wanted to imply :). And this last statement does not
imply that we need such an API. I'm not so sure anymore and
prefer to not work on it without a good plan.

> door open to spread the benefits around.  If you squelch format-patch, you
> would help people who would want to drive it from their cron job (perhaps
> they are on dial-up and they would rather batch things up than running
> format-patch and send-email from their post-receive hook).  If you squelch
> am, you would help people who use it as a part of their mailing list
> scanning software that runs unattended.  Of course, you could choose to
> squelch the "format-patch | am -3" pipeline in one go by redirecting the
> entire pipe to somewhere, instead of giving individual commands --quiet
> option.  If you did so, obviously the benefits won't be spread to users of
> these underlying commands.
>
> But I do not think squelching of these individual commands such as
> format-patch, am, and pull are so useful in the larger picture in the
> context of scripting; see below.
>
>>> I would write such a cron-job script to capture the log and send it only
>>> upon failure from the underlying command if I were doing this myself,
>>> though.
>>
>> This is the way I do it now and I'm surprised I found no other simple way
>> than writing a wrapper script for it. At least not with vixie-cron.
>
> Actually I am not so surprised.

My script is trivial.
It executes the command supplied, captures stderr and stdout to a
temporary file and if and only if the command does not return a
success code the contents of the file are echoed and this leads to
cron mailing the output.

> A cron job that contains a git pull most likely needs to be a script that
> wants to do many other things anyway, such as chdir into the target
> repository, make sure nobody (including yourself) did not by mistake went
> into the repository and made local changes that may interfere with the
> pull and if so abort, perform the pull, noticing its exit status, produce
> the error report and exit if pull fails, validate each new commits the
> pull brought in against some in-house coding standard, run a build test
> (perhaps "make test") if pull succeeded, noticing its exit status, produce
> the error report and exit if the build fails, install the build result if
> build succeeded, and so on.  Individual steps such as "git pull" and "make
> install" are only small self-contained building blocks in such a workflow,
> and it is not unusual for such a script to redirect output from the
> building blocks it uses and produce a summarized report at the very end of
> the run using the redirected output, while emitting messages on its own.
>
> In such an arrangement, having "a bit quieter than usual" option in the
> underlying command, which would be what we would want for these primarily
> interactive commands, is not very useful anyway, because the "quieter"
> output mode may drop some information you might want to include in the
> fuller report when something goes wrong, and filtering such "a bit
> quieter" output takes as much effort as filtering the output from the
> normal mode when there is nothing noteworthy to report and your script
> wants to squelch the output entirely.
>

ACK.