{"thread":{"id":"33734","subject":"[PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","startedAt":"2013-05-06T13:53:42Z","lastAt":"2013-07-02T18:51:50Z","messageCount":15,"participants":["Trond Hasle Amundsen","Junio C Hamano","Matthieu Moy","Michael Haggerty"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"216497","messageId":"15tsj20cizd.fsf@tux.uio.no","threadId":"33734","inReplyTo":null,"subject":"[PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Trond Hasle Amundsen","fromEmail":"t.h.amundsen@usit.uio.no","sentAt":"2013-05-06T13:53:42Z","receivedAt":"2013-05-06T13:53:42Z","isPatch":true,"sender":{"key":"t.h.amundsen@usit.uio.no","avatar":null},"body":"\nHello,\n\nThe included patch attempts to improve post-receive-email. It's a\ntrivial change, but one that helps us Gitolite users. Comments are\nwelcome, and this is my first attempt at contributing to the Git\nproject. Please keep me on CC as I'm not on the list.\n\n\n\n>From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001\nFrom: Trond Hasle Amundsen \nDate: Mon, 6 May 2013 15:41:25 +0200\nSubject: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config\n\nWhen getting the project description, we first try gitweb.description\nentry in repo.git/config, but repo.git/description takes precedence if\nit exists. This behaviour mimics that of Gitweb, and is what we want\nwhen using Gitolite, which deletes repo.git/description upon repo\ncreation and rather maintains a gitweb.description entry in\nrepo.git/config if a description is configured.\n\nSigned-off-by: Trond Hasle Amundsen \n---\n contrib/hooks/post-receive-email | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email\nindex 0e5b72d..6ce046a 100755\n--- a/contrib/hooks/post-receive-email\n+++ b/contrib/hooks/post-receive-email\n@@ -714,7 +714,14 @@ if [ -z \"$GIT_DIR\" ]; then\n \texit 1\n fi\n \n-projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n+# Get the repo's description. First try gitweb.description entry in\n+# repo.git/config, but repo.git/description takes precedence if it\n+# exists. This behaviour mimics that of Gitweb.\n+projectdesc=$(git config gitweb.description)\n+if [ -f \"$GIT_DIR/description\" ]; then\n+ projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n+fi\n+\n # Check if the description is unchanged from it's default, and shorten it to\n # a more manageable length if it is\n if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n-- \n1.7.1\n\n\n\n\nCheers,\n-- \nTrond H. Amundsen \nCenter for Information Technology Services, University of Oslo\n"},{"id":"216507","messageId":"15tfvy0cew5.fsf@tux.uio.no","threadId":"33734","inReplyTo":"15tsj20cizd.fsf@tux.uio.no","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Trond Hasle Amundsen","fromEmail":"t.h.amundsen@usit.uio.no","sentAt":"2013-05-06T15:22:02Z","receivedAt":"2013-05-06T15:22:02Z","isPatch":true,"sender":{"key":"t.h.amundsen@usit.uio.no","avatar":null},"body":"Trond Hasle Amundsen writes:\n\n> The included patch attempts to improve post-receive-email. It's a\n> trivial change, but one that helps us Gitolite users. Comments are\n> welcome, and this is my first attempt at contributing to the Git\n> project. Please keep me on CC as I'm not on the list.\n\nBah.. It seems I attached this as MIME, sorry about that. Here it is,\nproperly inlined this time:\n\n>From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001\nFrom: Trond Hasle Amundsen \nDate: Mon, 6 May 2013 15:41:25 +0200\nSubject: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config\n\nWhen getting the project description, we first try gitweb.description\nentry in repo.git/config, but repo.git/description takes precedence if\nit exists. This behaviour mimics that of Gitweb, and is what we want\nwhen using Gitolite, which deletes repo.git/description upon repo\ncreation and rather maintains a gitweb.description entry in\nrepo.git/config if a description is configured.\n\nSigned-off-by: Trond Hasle Amundsen \n---\n contrib/hooks/post-receive-email | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email\nindex 0e5b72d..6ce046a 100755\n--- a/contrib/hooks/post-receive-email\n+++ b/contrib/hooks/post-receive-email\n@@ -714,7 +714,14 @@ if [ -z \"$GIT_DIR\" ]; then\n \texit 1\n fi\n \n-projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n+# Get the repo's description. First try gitweb.description entry in\n+# repo.git/config, but repo.git/description takes precedence if it\n+# exists. This behaviour mimics that of Gitweb.\n+projectdesc=$(git config gitweb.description)\n+if [ -f \"$GIT_DIR/description\" ]; then\n+ projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n+fi\n+\n # Check if the description is unchanged from it's default, and shorten it to\n # a more manageable length if it is\n if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n-- \n1.7.1\n\n\nCheers,\n-- \nTrond H. Amundsen \nCenter for Information Technology Services, University of Oslo\n"},{"id":"216509","messageId":"7vtxmgruhc.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"15tsj20cizd.fsf@tux.uio.no","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-06T15:36:15Z","receivedAt":"2013-05-06T15:36:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Trond Hasle Amundsen writes:\n\n> Hello,\n>\n> The included patch attempts to improve post-receive-email. It's a\n\nPlease don't ;-)\n\nEh, actually, thanks for the patch.\n\nBut when you send a patch the next time around, please have the\nabove and the next three lines (i.e. \"introductory text\") _below_\nthe three-dash line.\n\n> trivial change, but one that helps us Gitolite users. Comments are\n> welcome, and this is my first attempt at contributing to the Git\n> project. Please keep me on CC as I'm not on the list.\n\n>\n> From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001\n> From: Trond Hasle Amundsen \n> Date: Mon, 6 May 2013 15:41:25 +0200\n> Subject: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config\n\nAnd remove these five lines above. We will read the authorship and\nsubject from the e-mail header of your message.\n\n>\n> When getting the project description, we first try gitweb.description\n> entry in repo.git/config, but repo.git/description takes precedence if\n> it exists. This behaviour mimics that of Gitweb, and is what we want\n> when using Gitolite, which deletes repo.git/description upon repo\n> creation and rather maintains a gitweb.description entry in\n> repo.git/config if a description is configured.\n>\n> Signed-off-by: Trond Hasle Amundsen \n> ---\n> contrib/hooks/post-receive-email | 9 ++++++++-\n> 1 files changed, 8 insertions(+), 1 deletions(-)\n>\n> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email\n> index 0e5b72d..6ce046a 100755\n> --- a/contrib/hooks/post-receive-email\n> +++ b/contrib/hooks/post-receive-email\n> @@ -714,7 +714,14 @@ if [ -z \"$GIT_DIR\" ]; then\n> \texit 1\n> fi\n> \n> -projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n> +# Get the repo's description. First try gitweb.description entry in\n> +# repo.git/config, but repo.git/description takes precedence if it\n> +# exists. This behaviour mimics that of Gitweb.\n> +projectdesc=$(git config gitweb.description)\n> +if [ -f \"$GIT_DIR/description\" ]; then\n> + projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n> +fi\n> +\n> # Check if the description is unchanged from it's default, and shorten it to\n> # a more manageable length if it is\n> if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n\nIf description file takes precedence, then the right order to do\nthis would be\n\n projectdesc=$(sed -ne 1p \"$GIT_DIR/description\" 2>/dev/null)\n if expr \"$projectdesc\" : \"Unnamed repository\" >/dev/null\n then\n : use it as is\n elif projectdesc=$(git config gitweb.description)\n then\n : use it as is\n else\n projectdesc=\"UNNAMED PROJECT\"\n fi\n\nto avoid calling \"git config\" when it is not even necessary.\n\nWe can obviously shorten it by making it less readable, e.g. \n\n projectdesc=$(sed -ne 1p \"$GIT_DIR/description\" 2>/dev/null)\n\n ! expr \"$projectdesc\" : \"Unnamed repository\" >/dev/null ||\n projectdesc=$(git config gitweb.description) ||\n projectdesc=\"UNNAMED PROJECT\"\n\nbut I do not think we want to go in that direction ;-)\n"},{"id":"216510","messageId":"vpq1u9kunba.fsf@grenoble-inp.fr","threadId":"33734","inReplyTo":"7vtxmgruhc.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-06T15:42:49Z","receivedAt":"2013-05-06T15:42:49Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Trond Hasle Amundsen writes:\n>\n>> Hello,\n>>\n>> The included patch attempts to improve post-receive-email. It's a\n>\n> Please don't ;-)\n\nMore precisely: you should have a look at git-multimail (in directory\ncontrib/, in branch for now pu/, or from\nhttps://github.com/mhagger/git-multimail) before spending time on\npost-receive-email.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"216514","messageId":"15t38u0cbw7.fsf@tux.uio.no","threadId":"33734","inReplyTo":"7vtxmgruhc.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Trond Hasle Amundsen","fromEmail":"t.h.amundsen@usit.uio.no","sentAt":"2013-05-06T16:26:48Z","receivedAt":"2013-05-06T16:26:48Z","isPatch":true,"sender":{"key":"t.h.amundsen@usit.uio.no","avatar":null},"body":"Junio C Hamano writes:\n\n> But when you send a patch the next time around, please have the\n> above and the next three lines (i.e. \"introductory text\") _below_\n> the three-dash line.\n\nAllright, noted.\n\n>> From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001\n>> From: Trond Hasle Amundsen \n>> Date: Mon, 6 May 2013 15:41:25 +0200\n>> Subject: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config\n>\n> And remove these five lines above. We will read the authorship and\n> subject from the e-mail header of your message.\n\nSo many rules.. ;) Also noted.\n\n>> +projectdesc=$(git config gitweb.description)\n>> +if [ -f \"$GIT_DIR/description\" ]; then\n>> + projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\" 2>/dev/null)\n>> +fi\n>> +\n>> # Check if the description is unchanged from it's default, and shorten it to\n>> # a more manageable length if it is\n>> if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n>\n> If description file takes precedence, then the right order to do\n> this would be\n>\n> projectdesc=$(sed -ne 1p \"$GIT_DIR/description\" 2>/dev/null)\n> if expr \"$projectdesc\" : \"Unnamed repository\" >/dev/null\n> then\n> : use it as is\n> elif projectdesc=$(git config gitweb.description)\n> then\n> : use it as is\n> else\n> projectdesc=\"UNNAMED PROJECT\"\n> fi\n>\n> to avoid calling \"git config\" when it is not even necessary.\n\nThat doesn't work, you'll always call \"git config\" unless the string\nmatches \"Unnamed repository\". If you negate the expr line it still\ndoesn't work. To avoid calling \"git config\" I'd rather suggest something\nlike this:\n\n projectdesc=$(sed -ne 1p \"$GIT_DIR/description\" 2>/dev/null)\n if [ -z \"$projectdesc\" ]; then\n projectdesc=$(git config gitweb.description)\n fi\n\nAnd let this block remain intact:\n\n if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n then\n projectdesc=\"UNNAMED PROJECT\"\n fi\n\nThe only change would then be the three added lines containing the if\nblock that calls \"git config\" if the \"projectdesc\" variable is\nempty. The idea is just to get the description from config if the\ndescription file doesn't exist.\n\nJust curious.. why would we avoid calling \"git config\" unless necessary?\n\nRegards,\n-- \nTrond H. Amundsen \nCenter for Information Technology Services, University of Oslo\n"},{"id":"216515","messageId":"15ty5bsax7m.fsf@tux.uio.no","threadId":"33734","inReplyTo":"vpq1u9kunba.fsf@grenoble-inp.fr","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Trond Hasle Amundsen","fromEmail":"t.h.amundsen@usit.uio.no","sentAt":"2013-05-06T16:29:17Z","receivedAt":"2013-05-06T16:29:17Z","isPatch":true,"sender":{"key":"t.h.amundsen@usit.uio.no","avatar":null},"body":"Matthieu Moy writes:\n\n>>> The included patch attempts to improve post-receive-email. It's a\n>>\n>> Please don't ;-)\n>\n> More precisely: you should have a look at git-multimail (in directory\n> contrib/, in branch for now pu/, or from\n> https://github.com/mhagger/git-multimail) before spending time on\n> post-receive-email.\n\nThanks for the tip, I'll check it out. I used post-receive-email out of\nconvenience, as it was already there.\n\nRegards,\n-- \nTrond H. Amundsen \nCenter for Information Technology Services, University of Oslo\n"},{"id":"216598","messageId":"7vwqrbmh4d.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"vpq1u9kunba.fsf@grenoble-inp.fr","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-07T06:36:02Z","receivedAt":"2013-05-07T06:36:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> More precisely: you should have a look at git-multimail (in directory\n> contrib/, in branch for now pu/, or from\n> https://github.com/mhagger/git-multimail) before spending time on\n> post-receive-email.\n\nOh, by the way, is this a vote of confidence in that topic, hinting\nthat we would want to advance it to 'next'?\n\nAs it is only adding a new script to contrib/, it could be argued\nthat we could even push it to 1.8.3-rc1, but until I hear from the\noriginal author (who will be the champion for that corner of the\ncontrib/ area), I wouldn't do so.\n"},{"id":"216606","messageId":"5188B165.3050709@alum.mit.edu","threadId":"33734","inReplyTo":"7vwqrbmh4d.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-05-07T07:46:45Z","receivedAt":"2013-05-07T07:46:45Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/07/2013 08:36 AM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n>> More precisely: you should have a look at git-multimail (in directory\n>> contrib/, in branch for now pu/, or from\n>> https://github.com/mhagger/git-multimail) before spending time on\n>> post-receive-email.\n> \n> Oh, by the way, is this a vote of confidence in that topic, hinting\n> that we would want to advance it to 'next'?\n> \n> As it is only adding a new script to contrib/, it could be argued\n> that we could even push it to 1.8.3-rc1, but until I hear from the\n> original author (who will be the champion for that corner of the\n> contrib/ area), I wouldn't do so.\n\nMy understanding is that we are waiting on two things:\n\n1. Consensus from the community. I would characterize the feedback on\nthe mailing list as limited in quantity but strongly positive [1-4] and\nI think that most/all of the wishes for post-receive-email features that\nwere originally omitted from git-multimail have been implemented in the\ncurrent version. Some of the mailing list feedback was about earlier\nversions. Do you want people to give feedback specifically about the\ncurrent version?\n\n2. For me to figure out what part of the git-multimail history I think\nshould be included in the Git project, do any necessary repository\nrewriting, and submit a pull request to you. The fact that I haven't\ngotten to this is due to the fact that I've been busy getting git-imerge\n[5] ready to present at GitMerge.\n\nMichael\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/209168\n(Branchaud)\n[2] http://article.gmane.org/gmane.comp.version-control.git/214941\n(Bjarmason)\n[3] http://article.gmane.org/gmane.comp.version-control.git/214987\n(Hiestand)\n[4] http://article.gmane.org/gmane.comp.version-control.git/216705 (Moy)\n[5] https://github.com/mhagger/git-imerge\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"216607","messageId":"vpq7gjbrzzz.fsf@grenoble-inp.fr","threadId":"33734","inReplyTo":"7vwqrbmh4d.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-07T07:49:20Z","receivedAt":"2013-05-07T07:49:20Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> More precisely: you should have a look at git-multimail (in directory\n>> contrib/, in branch for now pu/, or from\n>> https://github.com/mhagger/git-multimail) before spending time on\n>> post-receive-email.\n>\n> Oh, by the way, is this a vote of confidence in that topic, hinting\n> that we would want to advance it to 'next'?\n\nI definitely would like to see git-multimail in contrib/, and to have it\nconsidered as \"the recommended way to send emails from a hook\". It does\nall the old script did, and much more.\n\npost-receive-email can stay for people who don't have Python on their\nservers, or for existing users who don't want to migrate.\n\nMy preference would go for a subtree merge to keep the existing history\n(that would mean extracting a subdirectory of git-multimail's tree\nbefore merging it to git.git).\n\n> As it is only adding a new script to contrib/, it could be argued\n> that we could even push it to 1.8.3-rc1,\n\nOTOH, it's not urgent, people can already use git-multimail by taking it\nfrom GitHub.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"216616","messageId":"7vy5bqlu6t.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"vpq7gjbrzzz.fsf@grenoble-inp.fr","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-07T14:51:22Z","receivedAt":"2013-05-07T14:51:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> OTOH, it's not urgent, people can already use git-multimail by taking it\n> from GitHub.\n\nYes. There are less and less reason to rush things into contrib/\nthese days, which is a very good thing from ecosystem's point of\nview. It is a sign that Git has matured that my tree no longer has\nto be the promotion place for third-party add-ons.\n"},{"id":"216618","messageId":"7vr4hilt28.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"5188B165.3050709@alum.mit.edu","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-07T15:15:43Z","receivedAt":"2013-05-07T15:15:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> My understanding is that we are waiting on two things:\n>\n> 1. Consensus from the community. I would characterize the feedback on\n> the mailing list as limited in quantity but strongly positive [1-4] and\n> I think that most/all of the wishes for post-receive-email features that\n> were originally omitted from git-multimail have been implemented in the\n> current version. Some of the mailing list feedback was about earlier\n> versions. Do you want people to give feedback specifically about the\n> current version?\n>\n> 2. For me to figure out what part of the git-multimail history I think\n> should be included in the Git project, do any necessary repository\n> rewriting, and submit a pull request to you.\n\nBoth are intertwined.\n\nI was looking at the history of your project at GitHub. I got an\nimpression that it is better to evolve as a standalone project with\nits own rich history, and the longer I looked at it, the more\nconvinced I got that I shouldn't pull history from you.\n\nAs \"batteries included\" service for the end users, it may be\nconvenient to have a copy of a stable release of the script in the\ncontrib/ area, but I do not think if it is the best for the script\nto further develop it in my tree. I'd be just an unnecessary\nbottleneck.\n\nI have a mildly strong suspicion that a better approach might be to:\n\n - Copy the current stable snapshot to the contrib/ area, but mark\n it clearly that the copy is merely for convenience, meant for end\n users who choose not to pull from your authoritative GitHub\n repository, and the real development happens elsewhere;\n\n - Keep the development at your GitHub repository, with you as the\n project lead. People who are interested in evolving it gather\n and work there; and\n\n - Update what is in contrib/ in my tree with a stable snapshot,\n every once in a while (close to the release points of Git project\n or of MultiMail project).\n"},{"id":"216623","messageId":"vpq61yuol7t.fsf@grenoble-inp.fr","threadId":"33734","inReplyTo":"7vr4hilt28.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-05-07T15:36:54Z","receivedAt":"2013-05-07T15:36:54Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I have a mildly strong suspicion that a better approach might be to:\n>\n> - Copy the current stable snapshot to the contrib/ area, [...]\n>\n> - Keep the development at your GitHub repository, [...]\n>\n> - Update what is in contrib/ in my tree with a stable snapshot,\n> every once in a while [...]\n\nI think this is not very different from\n\n- merge the current version in the contrib/ area\n\n- keep the development at the GitHub repository\n\n- merge the GitHub repository into the git.git once in a while\n\n(which is essentially what happens with gitk and git-gui as far as I\nunderstood)\n\nI tend to prefer the \"merge\" approach to the \"copy files from one repo\nto another\", even if git_multimail is never edited directly from\ngit.git. I find it conceptually cleaner, and it gives a bit more\nflexibility (e.g. if someone accidentally commits in git.git's\nrepository, the commit would also be valid wrt git_multimail's GitHub\nrepo, and can serve as a pull request).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222312","messageId":"7v1u7iapzw.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"5188B165.3050709@alum.mit.edu","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-01T21:58:47Z","receivedAt":"2013-07-01T21:58:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> My understanding is that we are waiting on two things:\n>\n> 1. Consensus from the community. I would characterize the feedback on\n> the mailing list as limited in quantity but strongly positive [1-4] and\n> I think that most/all of the wishes for post-receive-email features that\n> were originally omitted from git-multimail have been implemented in the\n> current version. Some of the mailing list feedback was about earlier\n> versions. Do you want people to give feedback specifically about the\n> current version?\n>\n> 2. For me to figure out what part of the git-multimail history I think\n> should be included in the Git project, do any necessary repository\n> rewriting, and submit a pull request to you. The fact that I haven't\n> gotten to this is due to the fact that I've been busy getting git-imerge\n> [5] ready to present at GitMerge.\n\nPing, now GitMerge is over?\n\nNo need to hurry, but just to make sure this didn't disappear from\neverybody's radar.\n\nThanks.\n"},{"id":"222357","messageId":"51D2996B.8070503@alum.mit.edu","threadId":"33734","inReplyTo":"7v1u7iapzw.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-07-02T09:12:11Z","receivedAt":"2013-07-02T09:12:11Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 07/01/2013 11:58 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> My understanding is that we are waiting on two things:\n>>\n>> 1. Consensus from the community. I would characterize the feedback on\n>> the mailing list as limited in quantity but strongly positive [1-4] and\n>> I think that most/all of the wishes for post-receive-email features that\n>> were originally omitted from git-multimail have been implemented in the\n>> current version. Some of the mailing list feedback was about earlier\n>> versions. Do you want people to give feedback specifically about the\n>> current version?\n>>\n>> 2. For me to figure out what part of the git-multimail history I think\n>> should be included in the Git project, do any necessary repository\n>> rewriting, and submit a pull request to you. The fact that I haven't\n>> gotten to this is due to the fact that I've been busy getting git-imerge\n>> [5] ready to present at GitMerge.\n> \n> Ping, now GitMerge is over?\n\nYes, and its reverberations are slowly getting under control, too :-)\n\n> No need to hurry, but just to make sure this didn't disappear from\n> everybody's radar.\n\nI definitely haven't forgotten it. I wasn't so happy with the script's\nPython API, and was holding off on the final submission to avoid casting\nthe old way in stone. But I finally had some time over the last two\nweekends to convert to what I think is a more sensible system [1]. (I\nalso improved the test coverage considerably.)\n\nFeedback would be very welcome, especially from people who have tried\nout the old Python API. I am even willing to personally help people\nadapt to the new API, as it would help me verify that real-life\ncustomizations are now indeed easier. (Ævar, any news?)\n\nThis week I want to convert $WORK to the new version; after that I would\nfeel comfortable submitting to Git contrib.\n\n(By the way, the changes don't affect how the script can be configured\nvia \"git config\" settings, or its backwards compatibility with\npost-receive-email. The improvements are all to the Python API.)\n\nI have a logistical question: git-multimail doesn't have its own mailing\nlist, and GitHub doesn't offer one. I was thinking about setting up a\nGoogle group, but a few people at GitMerge suggested that I instead\ndirect discussion of git-multimail to the main Git mailing list. I\nwould slightly prefer that, but I would first like to make sure that the\nextra traffic (probably not much) would be welcome on the Git mailing list.\n\nMichael\n\n[1] \"master\" branch at https://github.com/mhagger/git-multimail\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"222389","messageId":"7vbo6k94mx.fsf@alter.siamese.dyndns.org","threadId":"33734","inReplyTo":"51D2996B.8070503@alum.mit.edu","subject":"Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-02T18:51:50Z","receivedAt":"2013-07-02T18:51:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> I have a logistical question: git-multimail doesn't have its own mailing\n> list, and GitHub doesn't offer one. I was thinking about setting up a\n> Google group, but a few people at GitMerge suggested that I instead\n> direct discussion of git-multimail to the main Git mailing list. I\n> would slightly prefer that, but I would first like to make sure that the\n> extra traffic (probably not much) would be welcome on the Git mailing list.\n\nI think we shouldn't be worried about the \"cluttering\" too much\nbefore we start. If the volume is too small, the messages relating\nto multimail may be drawfed by other traffic, but that is the same\nfor messages relating to any other parts of the system.\n\nIt only becomes a problem if the volume on multimail is too large\nbut most of the list readers are not interested in them. I somehow\nfind it hard to imagine that will happen soon.\n"}]}