{"thread":{"id":"16570","subject":"[PATCH] Implement rebase -q to fix pull --rebase -q","startedAt":"2008-12-03T04:06:52Z","lastAt":"2008-12-03T22:21:12Z","messageCount":8,"participants":["Tuncer Ayaz","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"97018","messageId":"1228277212-5917-1-git-send-email-tuncer.ayaz@gmail.com","threadId":"16570","inReplyTo":null,"subject":"[PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2008-12-03T04:06:52Z","receivedAt":"2008-12-03T04:06:52Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"This is needed on top of the fetch/pull -q/-v changes\nto make\n$ git pull --rebase -q\nas quiet as expected.\n\nSigned-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>\n---\n git-pull.sh   |    2 +-\n git-rebase.sh |   31 +++++++++++++++++++++++--------\n 2 files changed, 24 insertions(+), 9 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 1cac898..57fcee9 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -184,6 +184,6 @@ fi\n merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n test true = \"$rebase\" &&\n \texec git-rebase $strategy_args --onto $merge_head \\\n-\t${oldremoteref:-$merge_head}\n+\t$verbosity ${oldremoteref:-$merge_head}\n exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \\\n \t\"$merge_name\" HEAD $merge_head $verbosity\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 023a6dc..bbfdc2e 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[--interactive | -i] [-q] [-v] [--onto <newbase>] <upstream> [<branch>]'\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n@@ -45,7 +45,7 @@ strategy=recursive\n do_merge=\n dotest=\"$GIT_DIR\"/rebase-merge\n prec=4\n-verbose=\n+verbosity=1\n git_am_opt=\n \n continue_merge () {\n@@ -135,7 +135,10 @@ move_to_original_branch () {\n finish_rb_merge () {\n \tmove_to_original_branch\n \trm -r \"$dotest\"\n-\techo \"All done.\"\n+\tif test $verbosity -gt 0\n+\tthen\n+\t\techo \"All done.\"\n+\tfi\n }\n \n is_interactive () {\n@@ -288,8 +291,11 @@ do\n \t\tesac\n \t\tdo_merge=t\n \t\t;;\n+\t-q|--quiet)\n+\t\tverbosity=0\n+\t\t;;\n \t-v|--verbose)\n-\t\tverbose=t\n+\t\tverbosity=2\n \t\t;;\n \t--whitespace=*)\n \t\tgit_am_opt=\"$git_am_opt $1\"\n@@ -401,11 +407,14 @@ if test \"$upstream\" = \"$onto\" && test \"$mb\" = \"$onto\" &&\n then\n \t# Lazily switch to the target branch if needed...\n \ttest -z \"$switch_to\" || git checkout \"$switch_to\"\n-\techo >&2 \"Current branch $branch_name is up to date.\"\n+\tif test $verbosity -gt 0\n+\tthen\n+\t\techo >&2 \"Current branch $branch_name is up to date.\"\n+\tfi\n \texit 0\n fi\n \n-if test -n \"$verbose\"\n+if test $verbosity -gt 1\n then\n \techo \"Changes from $mb to $onto:\"\n \t# We want color (if set), but no pager\n@@ -413,7 +422,10 @@ then\n fi\n \n # Detach HEAD and reset the tree\n-echo \"First, rewinding head to replay your work on top of it...\"\n+if test $verbosity -gt 0\n+then\n+\techo \"First, rewinding head to replay your work on top of it...\"\n+fi\n git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n git update-ref ORIG_HEAD $branch\n \n@@ -421,7 +433,10 @@ git update-ref ORIG_HEAD $branch\n # we just fast forwarded.\n if test \"$mb\" = \"$branch\"\n then\n-\techo >&2 \"Fast-forwarded $branch_name to $onto_name.\"\n+\tif test $verbosity -gt 0\n+\tthen\n+\t\techo >&2 \"Fast-forwarded $branch_name to $onto_name.\"\n+\tfi\n \tmove_to_original_branch\n \texit 0\n fi\n-- \n1.6.0.2.GIT\n"},{"id":"97019","messageId":"4ac8254d0812022009t6eed5406ve2acb0b020240448@mail.gmail.com","threadId":"16570","inReplyTo":"1228277212-5917-1-git-send-email-tuncer.ayaz@gmail.com","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2008-12-03T04:09:50Z","receivedAt":"2008-12-03T04:09:50Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Dec 3, 2008 at 5:06 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:\n> This is needed on top of the fetch/pull -q/-v changes\n> to make\n> $ git pull --rebase -q\n> as quiet as expected.\n>\n> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>\n> ---\n>  git-pull.sh   |    2 +-\n>  git-rebase.sh |   31 +++++++++++++++++++++++--------\n>  2 files changed, 24 insertions(+), 9 deletions(-)\n>\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 1cac898..57fcee9 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -184,6 +184,6 @@ fi\n>  merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n>  test true = \"$rebase\" &&\n>        exec git-rebase $strategy_args --onto $merge_head \\\n> -       ${oldremoteref:-$merge_head}\n> +       $verbosity ${oldremoteref:-$merge_head}\n>  exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \\\n>        \"$merge_name\" HEAD $merge_head $verbosity\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 023a6dc..bbfdc2e 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -3,7 +3,7 @@\n>  # Copyright (c) 2005 Junio C Hamano.\n>  #\n>\n> -USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n> +USAGE='[--interactive | -i] [-q] [-v] [--onto <newbase>] <upstream> [<branch>]'\n>  LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n>  same name.  When the --onto option is provided the new branch starts\n>  out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n> @@ -45,7 +45,7 @@ strategy=recursive\n>  do_merge=\n>  dotest=\"$GIT_DIR\"/rebase-merge\n>  prec=4\n> -verbose=\n> +verbosity=1\n>  git_am_opt=\n>\n>  continue_merge () {\n> @@ -135,7 +135,10 @@ move_to_original_branch () {\n>  finish_rb_merge () {\n>        move_to_original_branch\n>        rm -r \"$dotest\"\n> -       echo \"All done.\"\n> +       if test $verbosity -gt 0\n> +       then\n> +               echo \"All done.\"\n> +       fi\n>  }\n>\n>  is_interactive () {\n> @@ -288,8 +291,11 @@ do\n>                esac\n>                do_merge=t\n>                ;;\n> +       -q|--quiet)\n> +               verbosity=0\n> +               ;;\n>        -v|--verbose)\n> -               verbose=t\n> +               verbosity=2\n>                ;;\n>        --whitespace=*)\n>                git_am_opt=\"$git_am_opt $1\"\n> @@ -401,11 +407,14 @@ if test \"$upstream\" = \"$onto\" && test \"$mb\" = \"$onto\" &&\n>  then\n>        # Lazily switch to the target branch if needed...\n>        test -z \"$switch_to\" || git checkout \"$switch_to\"\n> -       echo >&2 \"Current branch $branch_name is up to date.\"\n> +       if test $verbosity -gt 0\n> +       then\n> +               echo >&2 \"Current branch $branch_name is up to date.\"\n> +       fi\n\nIf anyone dislikes the additional three lines I could combine\nthe test with the action on one line. I'm just not sure that would\nmake it better, especially depending on log message length.\n\n>        exit 0\n>  fi\n>\n> -if test -n \"$verbose\"\n> +if test $verbosity -gt 1\n>  then\n>        echo \"Changes from $mb to $onto:\"\n>        # We want color (if set), but no pager\n> @@ -413,7 +422,10 @@ then\n>  fi\n>\n>  # Detach HEAD and reset the tree\n> -echo \"First, rewinding head to replay your work on top of it...\"\n> +if test $verbosity -gt 0\n> +then\n> +       echo \"First, rewinding head to replay your work on top of it...\"\n> +fi\n>  git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n>  git update-ref ORIG_HEAD $branch\n>\n> @@ -421,7 +433,10 @@ git update-ref ORIG_HEAD $branch\n>  # we just fast forwarded.\n>  if test \"$mb\" = \"$branch\"\n>  then\n> -       echo >&2 \"Fast-forwarded $branch_name to $onto_name.\"\n> +       if test $verbosity -gt 0\n> +       then\n> +               echo >&2 \"Fast-forwarded $branch_name to $onto_name.\"\n> +       fi\n>        move_to_original_branch\n>        exit 0\n>  fi\n> --\n> 1.6.0.2.GIT\n>\n>\n"},{"id":"97029","messageId":"7vej0pheww.fsf@gitster.siamese.dyndns.org","threadId":"16570","inReplyTo":"1228277212-5917-1-git-send-email-tuncer.ayaz@gmail.com","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-03T07:54:39Z","receivedAt":"2008-12-03T07:54:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:\n\n> This is needed on top of the fetch/pull -q/-v changes\n> to make\n> $ git pull --rebase -q\n> as quiet as expected.\n\nI am not sure if this is worth it, in the sense that it is not really\nquiet enough (iow, it is not what I expect even though you claim \"as\nexpected\" here), and in another sense that making it really quiet may not\nbe what we want anyway.\n\nHow are you dealing with messages from the actual replaying of each local\ncommit on top of what is fetched?  In order to be able to tell where you\nare when one of them fail in conflicts, you cannot stay silent while doing\nso.\n"},{"id":"97030","messageId":"4ac8254d0812030007w3217f6eei3d364ce2272930c3@mail.gmail.com","threadId":"16570","inReplyTo":"7vej0pheww.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2008-12-03T08:07:52Z","receivedAt":"2008-12-03T08:07:52Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:\n>\n>> This is needed on top of the fetch/pull -q/-v changes\n>> to make\n>> $ git pull --rebase -q\n>> as quiet as expected.\n>\n> I am not sure if this is worth it, in the sense that it is not really\n> quiet enough (iow, it is not what I expect even though you claim \"as\n\nJunio, sorry for using 'expected'.\nI thought about the wording while writing and had a feeling that 'expected'\nmay be too strong as it's my opinion only. I should have listened to myself :).\n\n> expected\" here), and in another sense that making it really quiet may not\n> be what we want anyway.\n\nI mainly use -q in automation where I only want output if something\ngoes wrong. Just like good old cp or mv do.\nDo you think this is the wrong way to go?\n\n> How are you dealing with messages from the actual replaying of each local\n> commit on top of what is fetched?  In order to be able to tell where you\n> are when one of them fail in conflicts, you cannot stay silent while doing\n> so.\n\nFair point.\n\nLog messages that are of importance to a failure should ideally be sent to\nstderr but I think caching log messages for the failure case would\nover-complicate\nmuch of the code and is not worth it. Also you may not always know which part\nof stdout messages are useful for the failure case and not getting the\nsame messages\non a rerun for many commands makes this hard to trace back, yeah.\n\nAs we've quietened pull/fetch/clone in a major already I am OK with leaving this\nchange out.\nI'm definitely not advocating adding/changing anything when it's not clear we\nwant the changed behavior. It's easier to keep out than to remove it\nlater on :).\n"},{"id":"97033","messageId":"7vr64pfyvg.fsf@gitster.siamese.dyndns.org","threadId":"16570","inReplyTo":"4ac8254d0812030007w3217f6eei3d364ce2272930c3@mail.gmail.com","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-03T08:26:27Z","receivedAt":"2008-12-03T08:26:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Tuncer Ayaz\" <tuncer.ayaz@gmail.com> writes:\n\n> I mainly use -q in automation where I only want output if something\n> goes wrong. Just like good old cp or mv do.\n> Do you think this is the wrong way to go?\n>\n>> How are you dealing with messages from the actual replaying of each local\n>> commit on top of what is fetched?  In order to be able to tell where you\n>> are when one of them fail in conflicts, you cannot stay silent while doing\n>> so.\n>\n> Fair point.\n\nAhh, ok, if this is for cron jobs, then it is understandable that:\n\n (1) You may want a successful \"git pull\" or \"git pull --rebase\" to be\n     absolutely silent about what it did; and\n\n (2) A failed \"git pull\" and \"git pull --rebase\" that produces information\n     other than the fact it failed would not help you, the receiver of a\n     cron job report, very much.  You would go to the repository when it\n     fails, reset the mess away, and then do the pull or pull-rebase\n     yourself manually anyway.\n\nIf that is the motivation behind the series, I think you would really want\nto squelch output from \"format-patch | am -3\" pipeline.\n\nAnother thing to consider is that, unlike simple single-operation commands\nsuch as \"mv\" or \"cp\" you mentioned, what \"git pull\" does is much more\ninvolved and has many different failure modes, so you cannot compare them\nfairly.  Simple commands can have a single \"quiet\" level, but I have a\nfeeling that there is a difference between \"quiet mode\" I expect when I am\nrunning \"git pull\" interactively and \"quiet mode\" I would want when I\nwould be driving \"git pull\" from a cron job.  IOW, you probably would want\nsomething like \"--really-quiet\" mode.\n\nI would write such a cron-job script to capture the log and send it only\nupon failure from the underlying command if I were doing this myself,\nthough.\n"},{"id":"97036","messageId":"4ac8254d0812030035n52fde4b3s29c0f525e175f123@mail.gmail.com","threadId":"16570","inReplyTo":"7vr64pfyvg.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2008-12-03T08:35:48Z","receivedAt":"2008-12-03T08:35:48Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Tuncer Ayaz\" <tuncer.ayaz@gmail.com> writes:\n>\n>> I mainly use -q in automation where I only want output if something\n>> goes wrong. Just like good old cp or mv do.\n>> Do you think this is the wrong way to go?\n>>\n>>> How are you dealing with messages from the actual replaying of each local\n>>> commit on top of what is fetched?  In order to be able to tell where you\n>>> are when one of them fail in conflicts, you cannot stay silent while doing\n>>> so.\n>>\n>> Fair point.\n>\n> Ahh, ok, if this is for cron jobs, then it is understandable that:\n>\n>  (1) You may want a successful \"git pull\" or \"git pull --rebase\" to be\n>     absolutely silent about what it did; and\n>\n>  (2) A failed \"git pull\" and \"git pull --rebase\" that produces information\n>     other than the fact it failed would not help you, the receiver of a\n>     cron job report, very much.  You would go to the repository when it\n>     fails, reset the mess away, and then do the pull or pull-rebase\n>     yourself manually anyway.\n>\n> If that is the motivation behind the series, I think you would really want\n> to squelch output from \"format-patch | am -3\" pipeline.\n\nYou mean I should follow this path and produce a patch series instead?\n\n> Another thing to consider is that, unlike simple single-operation commands\n> such as \"mv\" or \"cp\" you mentioned, what \"git pull\" does is much more\n> involved and has many different failure modes, so you cannot compare them\n> fairly.  Simple commands can have a single \"quiet\" level, but I have a\n> feeling that there is a difference between \"quiet mode\" I expect when I am\n> running \"git pull\" interactively and \"quiet mode\" I would want when I\n\nWe have the same expectation here and IDE writers also seem to expect that.\n\n> would be driving \"git pull\" from a cron job.  IOW, you probably would want\n> something like \"--really-quiet\" mode.\n\nYeah, it gets messy and in the current codebase. I am also not sure whether\nthe effort/benefit ratio is good enough.\n\n> I would write such a cron-job script to capture the log and send it only\n> upon failure from the underlying command if I were doing this myself,\n> though.\n\nThis is the way I do it now and I'm surprised I found no other simple way\nthan writing a wrapper script for it. At least not with vixie-cron.\n"},{"id":"97095","messageId":"7vljuxc672.fsf@gitster.siamese.dyndns.org","threadId":"16570","inReplyTo":"4ac8254d0812030035n52fde4b3s29c0f525e175f123@mail.gmail.com","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-03T21:14:09Z","receivedAt":"2008-12-03T21:14:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Tuncer Ayaz\" <tuncer.ayaz@gmail.com> writes:\n\n> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> Ahh, ok, if this is for cron jobs, then it is understandable that:\n>>\n>>  (1) You may want a successful \"git pull\" or \"git pull --rebase\" to be\n>>     absolutely silent about what it did; and\n>>\n>>  (2) A failed \"git pull\" and \"git pull --rebase\" that produces information\n>>     other than the fact it failed would not help you, the receiver of a\n>>     cron job report, very much.  You would go to the repository when it\n>>     fails, reset the mess away, and then do the pull or pull-rebase\n>>     yourself manually anyway.\n>>\n>> If that is the motivation behind the series, I think you would really want\n>> to squelch output from \"format-patch | am -3\" pipeline.\n>\n> You mean I should follow this path and produce a patch series instead?\n\nNot necessarily.  It is entirely up to you.\n\nAn important point at this point is that the patch as submitted, without\nsuch a change, will not be useful to achieve the goal (1) above, because\nit will still be chatty.\n\n>> would be driving \"git pull\" from a cron job.  IOW, you probably would want\n>> something like \"--really-quiet\" mode.\n>\n> Yeah, it gets messy and in the current codebase. I am also not sure whether\n> the effort/benefit ratio is good enough.\n\nI doubt \"the current codebase\" has more downside than upside as you seem\nto imply.  The way rebase uses layered set of other commands keeps the\ndoor open to spread the benefits around.  If you squelch format-patch, you\nwould help people who would want to drive it from their cron job (perhaps\nthey are on dial-up and they would rather batch things up than running\nformat-patch and send-email from their post-receive hook).  If you squelch\nam, you would help people who use it as a part of their mailing list\nscanning software that runs unattended.  Of course, you could choose to\nsquelch the \"format-patch | am -3\" pipeline in one go by redirecting the\nentire pipe to somewhere, instead of giving individual commands --quiet\noption.  If you did so, obviously the benefits won't be spread to users of\nthese underlying commands.\n\nBut I do not think squelching of these individual commands such as\nformat-patch, am, and pull are so useful in the larger picture in the\ncontext of scripting; see below.\n\n>> I would write such a cron-job script to capture the log and send it only\n>> upon failure from the underlying command if I were doing this myself,\n>> though.\n>\n> This is the way I do it now and I'm surprised I found no other simple way\n> than writing a wrapper script for it. At least not with vixie-cron.\n\nActually I am not so surprised.\n\nA cron job that contains a git pull most likely needs to be a script that\nwants to do many other things anyway, such as chdir into the target\nrepository, make sure nobody (including yourself) did not by mistake went\ninto the repository and made local changes that may interfere with the\npull and if so abort, perform the pull, noticing its exit status, produce\nthe error report and exit if pull fails, validate each new commits the\npull brought in against some in-house coding standard, run a build test\n(perhaps \"make test\") if pull succeeded, noticing its exit status, produce\nthe error report and exit if the build fails, install the build result if\nbuild succeeded, and so on.  Individual steps such as \"git pull\" and \"make\ninstall\" are only small self-contained building blocks in such a workflow,\nand it is not unusual for such a script to redirect output from the\nbuilding blocks it uses and produce a summarized report at the very end of\nthe run using the redirected output, while emitting messages on its own.\n\nIn such an arrangement, having \"a bit quieter than usual\" option in the\nunderlying command, which would be what we would want for these primarily\ninteractive commands, is not very useful anyway, because the \"quieter\"\noutput mode may drop some information you might want to include in the\nfuller report when something goes wrong, and filtering such \"a bit\nquieter\" output takes as much effort as filtering the output from the\nnormal mode when there is nothing noteworthy to report and your script\nwants to squelch the output entirely.\n"},{"id":"97100","messageId":"4ac8254d0812031421q6470f75er3bd8e4fce3929fc6@mail.gmail.com","threadId":"16570","inReplyTo":"7vljuxc672.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Implement rebase -q to fix pull --rebase -q","fromName":"Tuncer Ayaz","fromEmail":"tuncer.ayaz@gmail.com","sentAt":"2008-12-03T22:21:12Z","receivedAt":"2008-12-03T22:21:12Z","isPatch":true,"sender":{"key":"tuncer.ayaz@gmail.com","avatar":null},"body":"On Wed, Dec 3, 2008 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Tuncer Ayaz\" <tuncer.ayaz@gmail.com> writes:\n>\n>> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> ...\n>>> Ahh, ok, if this is for cron jobs, then it is understandable that:\n>>>\n>>>  (1) You may want a successful \"git pull\" or \"git pull --rebase\" to be\n>>>     absolutely silent about what it did; and\n>>>\n>>>  (2) A failed \"git pull\" and \"git pull --rebase\" that produces information\n>>>     other than the fact it failed would not help you, the receiver of a\n>>>     cron job report, very much.  You would go to the repository when it\n>>>     fails, reset the mess away, and then do the pull or pull-rebase\n>>>     yourself manually anyway.\n>>>\n>>> If that is the motivation behind the series, I think you would really want\n>>> to squelch output from \"format-patch | am -3\" pipeline.\n>>\n>> You mean I should follow this path and produce a patch series instead?\n>\n> Not necessarily.  It is entirely up to you.\n>\n> An important point at this point is that the patch as submitted, without\n> such a change, will not be useful to achieve the goal (1) above, because\n> it will still be chatty.\n\nI personally don't see a huge point right now in implementing -q\nin any more commands.\n\n>>> would be driving \"git pull\" from a cron job.  IOW, you probably would want\n>>> something like \"--really-quiet\" mode.\n>>\n>> Yeah, it gets messy and in the current codebase. I am also not sure whether\n>> the effort/benefit ratio is good enough.\n>\n> I doubt \"the current codebase\" has more downside than upside as you seem\n> to imply.  The way rebase uses layered set of other commands keeps the\n\nI think it gets \"messy\" if you start implementing more and more\nlog levels without an internal consistent logging API. That's\nall I wanted to imply :). And this last statement does not\nimply that we need such an API. I'm not so sure anymore and\nprefer to not work on it without a good plan.\n\n> door open to spread the benefits around.  If you squelch format-patch, you\n> would help people who would want to drive it from their cron job (perhaps\n> they are on dial-up and they would rather batch things up than running\n> format-patch and send-email from their post-receive hook).  If you squelch\n> am, you would help people who use it as a part of their mailing list\n> scanning software that runs unattended.  Of course, you could choose to\n> squelch the \"format-patch | am -3\" pipeline in one go by redirecting the\n> entire pipe to somewhere, instead of giving individual commands --quiet\n> option.  If you did so, obviously the benefits won't be spread to users of\n> these underlying commands.\n>\n> But I do not think squelching of these individual commands such as\n> format-patch, am, and pull are so useful in the larger picture in the\n> context of scripting; see below.\n>\n>>> I would write such a cron-job script to capture the log and send it only\n>>> upon failure from the underlying command if I were doing this myself,\n>>> though.\n>>\n>> This is the way I do it now and I'm surprised I found no other simple way\n>> than writing a wrapper script for it. At least not with vixie-cron.\n>\n> Actually I am not so surprised.\n\nMy script is trivial.\nIt executes the command supplied, captures stderr and stdout to a\ntemporary file and if and only if the command does not return a\nsuccess code the contents of the file are echoed and this leads to\ncron mailing the output.\n\n> A cron job that contains a git pull most likely needs to be a script that\n> wants to do many other things anyway, such as chdir into the target\n> repository, make sure nobody (including yourself) did not by mistake went\n> into the repository and made local changes that may interfere with the\n> pull and if so abort, perform the pull, noticing its exit status, produce\n> the error report and exit if pull fails, validate each new commits the\n> pull brought in against some in-house coding standard, run a build test\n> (perhaps \"make test\") if pull succeeded, noticing its exit status, produce\n> the error report and exit if the build fails, install the build result if\n> build succeeded, and so on.  Individual steps such as \"git pull\" and \"make\n> install\" are only small self-contained building blocks in such a workflow,\n> and it is not unusual for such a script to redirect output from the\n> building blocks it uses and produce a summarized report at the very end of\n> the run using the redirected output, while emitting messages on its own.\n>\n> In such an arrangement, having \"a bit quieter than usual\" option in the\n> underlying command, which would be what we would want for these primarily\n> interactive commands, is not very useful anyway, because the \"quieter\"\n> output mode may drop some information you might want to include in the\n> fuller report when something goes wrong, and filtering such \"a bit\n> quieter\" output takes as much effort as filtering the output from the\n> normal mode when there is nothing noteworthy to report and your script\n> wants to squelch the output entirely.\n>\n\nACK.\n"}]}