{"thread":{"id":"7146","subject":"[PATCH] Split sample update hook into post-receive hook","startedAt":"2007-03-08T04:16:18Z","lastAt":"2007-03-10T08:29:23Z","messageCount":10,"participants":["Shawn O. Pearce","Alex Riesen","Junio C Hamano","Sergey Vlasov"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"36591","messageId":"20070308041618.GA29744@spearce.org","threadId":"7146","inReplyTo":null,"subject":"[PATCH] Split sample update hook into post-receive hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-08T04:16:18Z","receivedAt":"2007-03-08T04:16:18Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Now that receive-pack supports the new post-receive hook, which\nwas specifically designed for sending out email notifications,\nwe should break the default update hook into two parts: one that\nrejects non-annotated tags (the update hook) and one that sends\nnotifications (the post-receive hook).\n\nFuture modifications to the default post-receive hook may include\nbundling notifications about multiple branches into one email, but\nI'm not going to do it as I don't personally use these hooks.  ;-)\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n\n Sorry about the mess here.  This is with -M -C, and yet we still\n get a huge diff on hooks--update due to the large number of lines\n removed from an existing file.  I think the diff would have been\n smaller if hooks--update was just considered to be new.  ;-)\n\n This is a crude hack to make the default hooks be split the way\n receive-pack now supports (and suggests).  Like I said above, I\n don't personally use these, so I'd really appreciate review from\n those who do.\n\n templates/{hooks--update => hooks--post-receive} |   49 ++---\n templates/hooks--update                          |  226 +---------------------\n 2 files changed, 26 insertions(+), 249 deletions(-)\n copy templates/{hooks--update => hooks--post-receive} (90%)\n\ndiff --git a/templates/hooks--update b/templates/hooks--post-receive\nsimilarity index 90%\ncopy from templates/hooks--update\ncopy to templates/hooks--post-receive\nindex 5b82b68..cface25 100644\n--- a/templates/hooks--update\n+++ b/templates/hooks--post-receive\n@@ -1,10 +1,12 @@\n #!/bin/sh\n #\n-# An example hook script to mail out commit update information.\n-# It can also blocks tags that aren't annotated.\n-# Called by git-receive-pack with arguments: refname sha1-old sha1-new\n+# An example hook script to mail out commit update information\n+# after a push has been successfully received into this repository.\n+# Called by git-receive-pack with arguments:\n+#    (refname sha1-old sha1-new)+\n #\n-# To enable this hook, make this file executable by \"chmod +x update\".\n+# To enable this hook, make this file executable by\n+# \"chmod +x post-receive\".\n #\n # Config\n # ------\n@@ -16,9 +18,6 @@\n #   This is the list that all pushes of annotated tags will go to.  Leave it\n #   blank to just use the mailinglist field.  The announce emails list the\n #   short log summary of the changes since the last annotated tag\n-# hooks.allowunannotated\n-#   This boolean sets whether unannotated tags will be allowed into the\n-#   repository.  By default they won't be.\n #\n # Notes\n # -----\n@@ -32,10 +31,10 @@ LOGBEGIN=\"- Log ----------------------------------------------------------------\n LOGEND=\"-----------------------------------------------------------------------\"\n DATEFORMAT=\"%F %R %z\"\n \n-# --- Command line\n-refname=\"$1\"\n-oldrev=\"$2\"\n-newrev=\"$3\"\n+# --- Config\n+projectdesc=$(cat $GIT_DIR/description)\n+recipients=$(git-repo-config hooks.mailinglist)\n+announcerecipients=$(git-repo-config hooks.announcelist)\n \n # --- Safety check\n if [ -z \"$GIT_DIR\" ]; then\n@@ -45,17 +44,18 @@ if [ -z \"$GIT_DIR\" ]; then\n \texit 1\n fi\n \n+while [ $# -gt 0 ]; do\n+\n+# --- Command line\n+refname=\"$1\"; shift\n+oldrev=\"$1\" ; shift\n+newrev=\"$1\" ; shift\n+\n if [ -z \"$refname\" -o -z \"$oldrev\" -o -z \"$newrev\" ]; then\n \techo \"Usage: $0 <ref> <oldrev> <newrev>\" >&2\n \texit 1\n fi\n \n-# --- Config\n-projectdesc=$(cat $GIT_DIR/description)\n-recipients=$(git-repo-config hooks.mailinglist)\n-announcerecipients=$(git-repo-config hooks.announcelist)\n-allowunannotated=$(git-repo-config --bool hooks.allowunannotated)\n-\n # --- Check types\n newrev_type=$(git-cat-file -t $newrev)\n \n@@ -64,11 +64,6 @@ case \"$refname\",\"$newrev_type\" in\n \t\t# un-annotated tag\n \t\trefname_type=\"tag\"\n \t\tshort_refname=${refname##refs/tags/}\n-\t\tif [ \"$allowunannotated\" != \"true\" ]; then\n-\t\t\techo \"*** The un-annotated tag, $short_refname is not allowed in this repository\" >&2\n-\t\t\techo \"*** Use 'git tag [ -a | -s ]' for tags you want to propagate.\" >&2\n-\t\t\texit 1\n-\t\tfi\n \t\t;;\n \trefs/tags/*,tag)\n \t\t# annotated tag\n@@ -90,12 +85,12 @@ case \"$refname\",\"$newrev_type\" in\n \t\tshort_refname=${refname##refs/remotes/}\n \t\t# Should this even be allowed?\n \t\techo \"*** Push-update of tracking branch, $refname.  No email generated.\" >&2\n-\t\texit 0\n+\t\tcontinue\n \t\t;;\n \t*)\n \t\t# Anything else (is there anything else?)\n \t\techo \"*** Update hook: unknown type of update, \\\"$newrev_type\\\", to ref $refname\" >&2\n-\t\texit 1\n+\t\tcontinue\n \t\t;;\n esac\n \n@@ -103,9 +98,9 @@ esac\n if [ -z \"$recipients\" ]; then\n \t# If the email isn't sent, then at least give the user some idea of what command\n \t# would generate the email at a later date\n-\techo \"*** No recipients found - no email will be sent, but the push will continue\" >&2\n+\techo \"*** No recipients found - no email was be sent.\" >&2\n \techo \"*** for $0 $1 $2 $3\" >&2\n-\texit 0\n+\tcontinue\n fi\n \n # --- Email parameters\n@@ -282,4 +277,4 @@ EOF\n ) | /usr/sbin/sendmail -t\n \n # --- Finished\n-exit 0\n+done\ndiff --git a/templates/hooks--update b/templates/hooks--update\nindex 5b82b68..cf883b2 100644\n--- a/templates/hooks--update\n+++ b/templates/hooks--update\n@@ -1,36 +1,15 @@\n #!/bin/sh\n #\n-# An example hook script to mail out commit update information.\n-# It can also blocks tags that aren't annotated.\n+# An example hook script to blocks tags that aren't annotated.\n # Called by git-receive-pack with arguments: refname sha1-old sha1-new\n #\n # To enable this hook, make this file executable by \"chmod +x update\".\n #\n # Config\n # ------\n-# hooks.mailinglist\n-#   This is the list that all pushes will go to; leave it blank to not send\n-#   emails frequently.  The log email will list every log entry in full between\n-#   the old ref value and the new ref value.\n-# hooks.announcelist\n-#   This is the list that all pushes of annotated tags will go to.  Leave it\n-#   blank to just use the mailinglist field.  The announce emails list the\n-#   short log summary of the changes since the last annotated tag\n # hooks.allowunannotated\n #   This boolean sets whether unannotated tags will be allowed into the\n #   repository.  By default they won't be.\n-#\n-# Notes\n-# -----\n-# All emails have their subjects prefixed with \"[SCM]\" to aid filtering.\n-# All emails include the headers \"X-Git-Refname\", \"X-Git-Oldrev\",\n-# \"X-Git-Newrev\", and \"X-Git-Reftype\" to enable fine tuned filtering and info.\n-\n-# --- Constants\n-EMAILPREFIX=\"[SCM] \"\n-LOGBEGIN=\"- Log -----------------------------------------------------------------\"\n-LOGEND=\"-----------------------------------------------------------------------\"\n-DATEFORMAT=\"%F %R %z\"\n \n # --- Command line\n refname=\"$1\"\n@@ -51,9 +30,6 @@ if [ -z \"$refname\" -o -z \"$oldrev\" -o -z \"$newrev\" ]; then\n fi\n \n # --- Config\n-projectdesc=$(cat $GIT_DIR/description)\n-recipients=$(git-repo-config hooks.mailinglist)\n-announcerecipients=$(git-repo-config hooks.announcelist)\n allowunannotated=$(git-repo-config --bool hooks.allowunannotated)\n \n # --- Check types\n@@ -62,34 +38,25 @@ newrev_type=$(git-cat-file -t $newrev)\n case \"$refname\",\"$newrev_type\" in\n \trefs/tags/*,commit)\n \t\t# un-annotated tag\n-\t\trefname_type=\"tag\"\n \t\tshort_refname=${refname##refs/tags/}\n \t\tif [ \"$allowunannotated\" != \"true\" ]; then\n \t\t\techo \"*** The un-annotated tag, $short_refname is not allowed in this repository\" >&2\n \t\t\techo \"*** Use 'git tag [ -a | -s ]' for tags you want to propagate.\" >&2\n \t\t\texit 1\n \t\tfi\n+\t\texit 0\n \t\t;;\n \trefs/tags/*,tag)\n \t\t# annotated tag\n-\t\trefname_type=\"annotated tag\"\n-\t\tshort_refname=${refname##refs/tags/}\n-\t\t# change recipients\n-\t\tif [ -n \"$announcerecipients\" ]; then\n-\t\t\trecipients=\"$announcerecipients\"\n-\t\tfi\n+\t\texit 0\n \t\t;;\n \trefs/heads/*,commit)\n \t\t# branch\n-\t\trefname_type=\"branch\"\n-\t\tshort_refname=${refname##refs/heads/}\n+\t\texit 0\n \t\t;;\n \trefs/remotes/*,commit)\n \t\t# tracking branch\n-\t\trefname_type=\"tracking branch\"\n-\t\tshort_refname=${refname##refs/remotes/}\n \t\t# Should this even be allowed?\n-\t\techo \"*** Push-update of tracking branch, $refname.  No email generated.\" >&2\n \t\texit 0\n \t\t;;\n \t*)\n@@ -98,188 +65,3 @@ case \"$refname\",\"$newrev_type\" in\n \t\texit 1\n \t\t;;\n esac\n-\n-# Check if we've got anyone to send to\n-if [ -z \"$recipients\" ]; then\n-\t# If the email isn't sent, then at least give the user some idea of what command\n-\t# would generate the email at a later date\n-\techo \"*** No recipients found - no email will be sent, but the push will continue\" >&2\n-\techo \"*** for $0 $1 $2 $3\" >&2\n-\texit 0\n-fi\n-\n-# --- Email parameters\n-committer=$(git show --pretty=full -s $newrev | grep \"^Commit: \" | sed -e \"s/^Commit: //\")\n-describe=$(git describe $newrev 2>/dev/null)\n-if [ -z \"$describe\" ]; then\n-\tdescribe=$newrev\n-fi\n-\n-# --- Email (all stdout will be the email)\n-(\n-# Generate header\n-cat <<-EOF\n-From: $committer\n-To: $recipients\n-Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname now at $describe\n-X-Git-Refname: $refname\n-X-Git-Reftype: $refname_type\n-X-Git-Oldrev: $oldrev\n-X-Git-Newrev: $newrev\n-\n-Hello,\n-\n-This is an automated email from the git hooks/update script, it was\n-generated because a ref change was pushed to the repository.\n-\n-Updating $refname_type, $short_refname,\n-EOF\n-\n-case \"$refname_type\" in\n-\t\"tracking branch\"|branch)\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new branch\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"  as a new  $refname_type\"\n-\t\t    echo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"\"\n-\t\t\techo $LOGBEGIN\n-\t\t\t# This shows all log entries that are not already covered by\n-\t\t\t# another ref - i.e. commits that are now accessible from this\n-\t\t\t# ref that were previously not accessible\n-\t\t\tgit log $newrev --not --all\n-\t\t\techo $LOGEND\n-\t\telse\n-\t\t\t# oldrev is valid\n-\t\t\toldrev_type=$(git-cat-file -t \"$oldrev\")\n-\n-\t\t\t# Now the problem is for cases like this:\n-\t\t\t#   * --- * --- * --- * (oldrev)\n-\t\t\t#          \\\n-\t\t\t#           * --- * --- * (newrev)\n-\t\t\t# i.e. there is no guarantee that newrev is a strict subset\n-\t\t\t# of oldrev - (would have required a force, but that's allowed).\n-\t\t\t# So, we can't simply say rev-list $oldrev..$newrev.  Instead\n-\t\t\t# we find the common base of the two revs and list from there\n-\t\t\tbaserev=$(git-merge-base $oldrev $newrev)\n-\n-\t\t\t# Commit with a parent\n-\t\t\tfor rev in $(git-rev-list $newrev --not $baserev --all)\n-\t\t\tdo\n-\t\t\t\trevtype=$(git-cat-file -t \"$rev\")\n-\t\t\t\techo \"       via  $rev ($revtype)\"\n-\t\t\tdone\n-\t\t\tif [ \"$baserev\" = \"$oldrev\" ]; then\n-\t\t\t\techo \"      from  $oldrev ($oldrev_type)\"\n-\t\t\telse\n-\t\t\t\techo \"  based on  $baserev\"\n-\t\t\t\techo \"      from  $oldrev ($oldrev_type)\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \"This ref update crossed a branch point; i.e. the old rev is not a strict subset\"\n-\t\t\t\techo \"of the new rev.  This occurs, when you --force push a change in a situation\"\n-\t\t\t\techo \"like this:\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \" * -- * -- B -- O -- O -- O ($oldrev)\"\n-\t\t\t\techo \"            \\\\\"\n-\t\t\t\techo \"             N -- N -- N ($newrev)\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \"Therefore, we assume that you've already had alert emails for all of the O\"\n-\t\t\t\techo \"revisions, and now give you all the revisions in the N branch from the common\"\n-\t\t\t\techo \"base, B ($baserev), up to the new revision.\"\n-\t\t\tfi\n-\t\t\techo \"\"\n-\t\t\techo $LOGBEGIN\n-\t\t\tgit log $newrev --not $baserev --all\n-\t\t\techo $LOGEND\n-\t\t\techo \"\"\n-\t\t\techo \"Diffstat:\"\n-\t\t\tgit-diff-tree --no-color --stat -M -C --find-copies-harder $baserev..$newrev\n-\t\tfi\n-\t\t;;\n-\t\"annotated tag\")\n-\t\t# Should we allow changes to annotated tags?\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new atag\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\telse\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"      from  $oldrev\"\n-\t\tfi\n-\n-\t\t# If this tag succeeds another, then show which tag it replaces\n-\t\tprevtag=$(git describe $newrev^ 2>/dev/null | sed 's/-g.*//')\n-\t\tif [ -n \"$prevtag\" ]; then\n-\t\t\techo \"  replaces  $prevtag\"\n-\t\tfi\n-\n-\t\t# Read the tag details\n-\t\teval $(git cat-file tag $newrev | \\\n-\t\t\tsed -n '4s/tagger \\([^>]*>\\)[^0-9]*\\([0-9]*\\).*/tagger=\"\\1\" ts=\"\\2\"/p')\n-\t\ttagged=$(date --date=\"1970-01-01 00:00:00 +0000 $ts seconds\" +\"$DATEFORMAT\")\n-\n-\t\techo \" tagged by  $tagger\"\n-\t\techo \"        on  $tagged\"\n-\n-\t\techo \"\"\n-\t\techo $LOGBEGIN\n-\t\techo \"\"\n-\n-\t\tif [ -n \"$prevtag\" ]; then\n-\t\t\tgit rev-list --pretty=short \"$prevtag..$newrev\" | git shortlog\n-\t\telse\n-\t\t\tgit rev-list --pretty=short $newrev | git shortlog\n-\t\tfi\n-\n-\t\techo $LOGEND\n-\t\techo \"\"\n-\t\t;;\n-\t*)\n-\t\t# By default, unannotated tags aren't allowed in; if\n-\t\t# they are though, it's debatable whether we would even want an\n-\t\t# email to be generated; however, I don't want to add another config\n-\t\t# option just for that.\n-\t\t#\n-\t\t# Unannotated tags are more about marking a point than releasing\n-\t\t# a version; therefore we don't do the shortlog summary that we\n-\t\t# do for annotated tags above - we simply show that the point has\n-\t\t# been marked, and print the log message for the marked point for\n-\t\t# reference purposes\n-\t\t#\n-\t\t# Note this section also catches any other reference type (although\n-\t\t# there aren't any) and deals with them in the same way.\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new tag\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"  as a new  $refname_type\"\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\telse\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"      from  $oldrev\"\n-\t\tfi\n-\t\techo \"\"\n-\t\techo $LOGBEGIN\n-\t\tgit-show --no-color --root -s $newrev\n-\t\techo $LOGEND\n-\t\techo \"\"\n-\t\t;;\n-esac\n-\n-# Footer\n-cat <<-EOF\n-\n-hooks/update\n----\n-Git Source Code Management System\n-$0 $1 \\\\\n-  $2 \\\\\n-  $3\n-EOF\n-#) | cat >&2\n-) | /usr/sbin/sendmail -t\n-\n-# --- Finished\n-exit 0\n-- \n1.5.0.3.927.g2432c\n"},{"id":"36596","messageId":"81b0412b0703080026v6f3990c3x2cefca661b64e00d@mail.gmail.com","threadId":"7146","inReplyTo":"20070308041618.GA29744@spearce.org","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-08T08:26:25Z","receivedAt":"2007-03-08T08:26:25Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/8/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> +# Called by git-receive-pack with arguments:\n> +#    (refname sha1-old sha1-new)+\n>  #\n\nWhat do you do if this breaks because of too many refs passed?\n"},{"id":"36597","messageId":"20070308083317.GB30289@spearce.org","threadId":"7146","inReplyTo":"81b0412b0703080026v6f3990c3x2cefca661b64e00d@mail.gmail.com","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-08T08:33:17Z","receivedAt":"2007-03-08T08:33:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> wrote:\n> On 3/8/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> >+# Called by git-receive-pack with arguments:\n> >+#    (refname sha1-old sha1-new)+\n> > #\n> \n> What do you do if this breaks because of too many refs passed?\n\nDie a horrible horrible death?\n\nThat's certainly a problem in receive-pack.  It should (somehow)\nbreak long invocations up, much like what xargs winds up doing.\nProblem is that limit is OS dependent... so uh, yea...\n\n-- \nShawn.\n"},{"id":"36600","messageId":"7vy7m8aytt.fsf@assigned-by-dhcp.cox.net","threadId":"7146","inReplyTo":"20070308083317.GB30289@spearce.org","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-08T09:06:54Z","receivedAt":"2007-03-08T09:06:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Alex Riesen <raa.lkml@gmail.com> wrote:\n>> On 3/8/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n>> >+# Called by git-receive-pack with arguments:\n>> >+#    (refname sha1-old sha1-new)+\n>> > #\n>> \n>> What do you do if this breaks because of too many refs passed?\n>\n> Die a horrible horrible death?\n>\n> That's certainly a problem in receive-pack.  It should (somehow)\n> break long invocations up, much like what xargs winds up doing.\n> Problem is that limit is OS dependent... so uh, yea...\n\nI suspect that it is deeper than that.  Think about why having\n\"everything at once\" is better than \"one at a time\".\n\nPotentially you could have a rule that says \"these should be\nupdated together\" (or the other way around).  If you split the\nset of refs at arbitrary limit, like xargs does, you would lose\nthat advantage.  We could take stdin to solve that and shell\nscripts should be able to handle that as refnames do not contain\nshell metacharacters.\n\nBut this is only true if you want to make it really nice.  I\npersonally feel that nobody would scream if pushing 1300 refs at\nonce (4K pages and MAX_ARG_PAGES at 32 would give 128K for\n**argv and its strings, and one ref's worth of data is two\n40-digit hex plus refname, roughly 100-byte per ref) is not\nsupported and always failed.\n"},{"id":"36601","messageId":"20070308091313.GC30289@spearce.org","threadId":"7146","inReplyTo":"7vy7m8aytt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-08T09:13:13Z","receivedAt":"2007-03-08T09:13:13Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> I suspect that it is deeper than that.  Think about why having\n> \"everything at once\" is better than \"one at a time\".\n> \n> Potentially you could have a rule that says \"these should be\n> updated together\" (or the other way around).  If you split the\n> set of refs at arbitrary limit, like xargs does, you would lose\n> that advantage.\n\nYes, I think the documentation says something about that... ;-)\n\n> We could take stdin to solve that and shell\n> scripts should be able to handle that as refnames do not contain\n> shell metacharacters.\n\nNever even occurred to me, because I was trying to keep the hook\ninterface \"simple\".\n\n> But this is only true if you want to make it really nice.  I\n> personally feel that nobody would scream if pushing 1300 refs at\n> once (4K pages and MAX_ARG_PAGES at 32 would give 128K for\n> **argv and its strings, and one ref's worth of data is two\n> 40-digit hex plus refname, roughly 100-byte per ref) is not\n> supported and always failed.\n\nAgree completely.  I'm not too worried about it.  1300 ref push is\njust not going to really occur in practice; that is just insane.\n30 refs, maybe.\n\n-- \nShawn.\n"},{"id":"36604","messageId":"20070308124024.d20e29c9.vsu@altlinux.ru","threadId":"7146","inReplyTo":"20070308091313.GC30289@spearce.org","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Sergey Vlasov","fromEmail":"vsu@altlinux.ru","sentAt":"2007-03-08T09:40:24Z","receivedAt":"2007-03-08T09:40:24Z","isPatch":true,"sender":{"key":"vsu@altlinux.ru","avatar":"https://avatars.githubusercontent.com/u/616082?v=4"},"body":"On Thu, 8 Mar 2007 04:13:13 -0500 Shawn O. Pearce wrote:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n[...]\n> > But this is only true if you want to make it really nice.  I\n> > personally feel that nobody would scream if pushing 1300 refs at\n> > once (4K pages and MAX_ARG_PAGES at 32 would give 128K for\n> > **argv and its strings, and one ref's worth of data is two\n> > 40-digit hex plus refname, roughly 100-byte per ref) is not\n> > supported and always failed.\n>\n> Agree completely.  I'm not too worried about it.  1300 ref push is\n> just not going to really occur in practice; that is just insane.\n> 30 refs, maybe.\n\nIt is not completely insane - e.g., the current klibc repository\nalready contains 338 tags.  Being unable to use \"git push --tags\" to\nan initially empty repository does not look good.\n\nSo could you please switch to passing refs through stdin while we\nstill can do it without breaking public interfaces?\n"},{"id":"36607","messageId":"81b0412b0703080157n413de6f6q35ae24e2620df91d@mail.gmail.com","threadId":"7146","inReplyTo":"7vy7m8aytt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-08T09:57:01Z","receivedAt":"2007-03-08T09:57:01Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/8/07, Junio C Hamano <junkio@cox.net> wrote:\n> But this is only true if you want to make it really nice.  I\n> personally feel that nobody would scream if pushing 1300 refs at\n> once (4K pages and MAX_ARG_PAGES at 32 would give 128K for\n> **argv and its strings, and one ref's worth of data is two\n> 40-digit hex plus refname, roughly 100-byte per ref) is not\n> supported and always failed.\n\nI'm not too worried about linux. It wont have any problems\neven if you supply megabytes of arguments (if someone will\nreally need such lists, he can increase MAX_ARG_PAGES\nand be done with it).\n\nThe proprietary OS' will have the problem, though. And far sooner\nthan 1300 refs (w2k has only 32767 bytes for command line).\nBesides, don't overestimate peoples readiness to be careful\nabout reference names. I would expect reference names over\n100 bytes in length to happen regularly (generated from file names\nappended with a timestamp, for example).\n\nMaybe provide this hooks with simply formatted list on stdin? I.e.\n\n<old-ref> <new-ref> <ref-name> LF\n"},{"id":"36609","messageId":"20070308100237.GF30289@spearce.org","threadId":"7146","inReplyTo":"81b0412b0703080157n413de6f6q35ae24e2620df91d@mail.gmail.com","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-08T10:02:37Z","receivedAt":"2007-03-08T10:02:37Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> wrote:\n> The proprietary OS' will have the problem, though. And far sooner\n> than 1300 refs (w2k has only 32767 bytes for command line).\n> Besides, don't overestimate peoples readiness to be careful\n> about reference names. I would expect reference names over\n> 100 bytes in length to happen regularly (generated from file names\n> appended with a timestamp, for example).\n\nCygwin's lifted that argument handling to be unlimited.  But yes,\nthe point holds, not all OSen will do well with long ref names\nand a lot of refs (such as in an initial push of a very verbosely\nnamed project).\n \n> Maybe provide this hooks with simply formatted list on stdin? I.e.\n> \n> <old-ref> <new-ref> <ref-name> LF\n\nYea, exactly what I was thinking.  Easily read on stdin using 'read'\nin shell, or in Perl, or, in C, or in ...  ;-)\n\n-- \nShawn.\n"},{"id":"36618","messageId":"81b0412b0703080409u5ae64698tfa70a8ba2de65df@mail.gmail.com","threadId":"7146","inReplyTo":"20070308100237.GF30289@spearce.org","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-08T12:09:07Z","receivedAt":"2007-03-08T12:09:07Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/8/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> > The proprietary OS' will have the problem, though. And far sooner\n> > than 1300 refs (w2k has only 32767 bytes for command line).\n> > Besides, don't overestimate peoples readiness to be careful\n> > about reference names. I would expect reference names over\n> > 100 bytes in length to happen regularly (generated from file names\n> > appended with a timestamp, for example).\n>\n> Cygwin's lifted that argument handling to be unlimited.\n\nActually, it didn't at all. Cygwin conveniently forgets that not all\nprograms use cygwin1.dll. Cygwin is just the wrong place\nwere the problems of windows stupidity have to be fixed,\nand so it does not fix them.\n"},{"id":"36741","messageId":"20070310082923.GA4092@spearce.org","threadId":"7146","inReplyTo":"20070308124024.d20e29c9.vsu@altlinux.ru","subject":"Re: [PATCH] Split sample update hook into post-receive hook","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-10T08:29:23Z","receivedAt":"2007-03-10T08:29:23Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sergey Vlasov <vsu@altlinux.ru> wrote:\n> On Thu, 8 Mar 2007 04:13:13 -0500 Shawn O. Pearce wrote:\n> > Agree completely.  I'm not too worried about it.  1300 ref push is\n> > just not going to really occur in practice; that is just insane.\n> > 30 refs, maybe.\n> \n> It is not completely insane - e.g., the current klibc repository\n> already contains 338 tags.  Being unable to use \"git push --tags\" to\n> an initially empty repository does not look good.\n> \n> So could you please switch to passing refs through stdin while we\n> still can do it without breaking public interfaces?\n\nFixed with my latest 8 patch series.  We now pass the ref data\nto the new {pre,post}-receive hooks by stdin, rather than as\ncommand line arguments.\n\nThanks for the reality check.  ;-)\n\n-- \nShawn.\n"}]}