patchImplement rebase -q to fix pull --rebase -q

> 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
>
>

> 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

> 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.

> "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

> 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?

>> 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.

> "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.
>