{"thread":{"id":"11903","subject":"[PATCH v2] compat: Add simplified merge sort implementation from glibc","startedAt":"2008-02-05T21:10:44Z","lastAt":"2008-02-11T21:16:57Z","messageCount":17,"participants":["Brian Downing","Johannes Schindelin","Junio C Hamano","Nicolas Pitre","Jari Aalto","Mike Hommey","Frank Lichtenheld","Aidan Van Dyk"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"67556","messageId":"20080205211044.GP26392@lavos.net","threadId":"11903","inReplyTo":null,"subject":"[PATCH v2] compat: Add simplified merge sort implementation from glibc","fromName":"Brian Downing","fromEmail":"bdowning-ou/tddhfglreowh0uzbu5w@public.gmane.org","sentAt":"2008-02-05T21:10:44Z","receivedAt":"2008-02-05T21:10:44Z","isPatch":true,"sender":{"key":"bdowning-ou/tddhfglreowh0uzbu5w@public.gmane.org","avatar":null},"body":"\nqsort in Windows 2000 (and various other C libraries) is a Quicksort\nwith the usual O(n^2) worst case. Unfortunately, sorting Git trees\nseems to get very close to that worst case quite often:\n\n $ /git/gitbad runstatus\n # On branch master\n qsort, nmemb = 30842\n done, 237838087 comparisons.\n\nThis patch adds a simplified version of the merge sort that is glibc's\nqsort(3). As a merge sort, this needs a temporary array equal in size\nto the array that is to be sorted, but has a worst-case performance of\nO(n log n).\n\nThe complexity that was removed is:\n\n* Doing direct stores for word-size and -aligned data.\n* Falling back to quicksort if the allocation required to perform the\n merge sort would likely push the machine into swap.\n\nEven with these simplifications, this seems to outperform the Windows\nqsort(3) implementation, even in Windows XP (where it is \"fixed\" and\ndoesn't trigger O(n^2) complexity on trees).\n\n[jes: moved into compat/qsort.c, as per Johannes Sixt's suggestion]\n[bcd: removed gcc-ism, thanks to Edgar Toernig. renamed make variable\n per Junio's comment.]\n\nSigned-off-by: Brian Downing \nSigned-off-by: Steffen Prohaska \nSigned-off-by: Johannes Schindelin \n---\n Here it is again. Sorry about the mail screwup.\n\n -bcd\n\n Makefile | 9 ++++++++\n compat/qsort.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++\n git-compat-util.h | 6 +++++\n 3 files changed, 75 insertions(+), 0 deletions(-)\n create mode 100644 compat/qsort.c\n\ndiff --git a/Makefile b/Makefile\nindex 92341c4..a0e5c0c 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -137,6 +137,11 @@ all::\n # Define THREADED_DELTA_SEARCH if you have pthreads and wish to exploit\n # parallel delta searching when packing objects.\n #\n+# Define INTERNAL_QSORT to use Git's implementation of qsort(), which\n+# is a simplified version of the merge sort used in glibc. This is\n+# recommended if Git triggers O(n^2) complexity in your\n+# implementation's qsort().\n+#\n \n GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE\n \t@$(SHELL_PATH) ./GIT-VERSION-GEN\n@@ -722,6 +727,10 @@ ifdef NO_MEMMEM\n \tCOMPAT_CFLAGS += -DNO_MEMMEM\n \tCOMPAT_OBJS += compat/memmem.o\n endif\n+ifdef INTERNAL_QSORT\n+\tCOMPAT_CFLAGS += -DINTERNAL_QSORT\n+\tCOMPAT_OBJS += compat/qsort.o\n+endif\n \n ifdef THREADED_DELTA_SEARCH\n \tBASIC_CFLAGS += -DTHREADED_DELTA_SEARCH\ndiff --git a/compat/qsort.c b/compat/qsort.c\nnew file mode 100644\nindex 0000000..8663889\n--- /dev/null\n+++ b/compat/qsort.c\n@@ -0,0 +1,60 @@\n+#include \"../git-compat-util.h\"\n+\n+/* This merge sort implementation is simplified from glibc's. */\n+static void msort_with_tmp(void *b, size_t n, size_t s,\n+\t\t\t int (*cmp)(const void *, const void *),\n+\t\t\t char *t)\n+{\n+\tchar *tmp;\n+\tchar *b1, *b2;\n+\tsize_t n1, n2;\n+\n+\tif (n <= 1)\n+\t\treturn;\n+\n+\tn1 = n / 2;\n+\tn2 = n - n1;\n+\tb1 = b;\n+\tb2 = (char *)b + (n1 * s);\n+\n+\tmsort_with_tmp(b1, n1, s, cmp, t);\n+\tmsort_with_tmp(b2, n2, s, cmp, t);\n+\n+\ttmp = t;\n+\n+\twhile (n1 > 0 && n2 > 0) {\n+\t\tif (cmp(b1, b2) <= 0) {\n+\t\t\tmemcpy(tmp, b1, s);\n+\t\t\ttmp += s;\n+\t\t\tb1 += s;\n+\t\t\t--n1;\n+\t\t} else {\n+\t\t\tmemcpy(tmp, b2, s);\n+\t\t\ttmp += s;\n+\t\t\tb2 += s;\n+\t\t\t--n2;\n+\t\t}\n+\t}\n+\tif (n1 > 0)\n+\t\tmemcpy(tmp, b1, n1 * s);\n+\tmemcpy(b, t, (n - n2) * s);\n+}\n+\n+void git_qsort(void *b, size_t n, size_t s,\n+\t int (*cmp)(const void *, const void *))\n+{\n+\tconst size_t size = n * s;\n+\n+\tif (size < 1024) {\n+\t\tchar buf[1024];\n+\n+\t\t/* The temporary array is small, so put it on\n+\t\t the stack. */\n+\t\tmsort_with_tmp(b, n, s, cmp, buf);\n+\t} else {\n+\t\t/* It's somewhat large, so malloc it. */\n+\t\tchar *tmp = malloc(size);\n+\t\tmsort_with_tmp(b, n, s, cmp, tmp);\n+\t\tfree(tmp);\n+\t}\n+}\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 4df90cb..0514604 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -426,4 +426,10 @@ static inline int strtol_i(char const *s, int base, int *result)\n \treturn 0;\n }\n \n+#ifdef INTERNAL_QSORT\n+void git_qsort(void *base, size_t nmemb, size_t size,\n+\t int(*compar)(const void *, const void *));\n+#define qsort git_qsort\n+#endif\n+\n #endif\n-- \n1.5.4.rc3\n"},{"id":"67566","messageId":"alpine.LSU.1.00.0802052220500.8543@racer.site","threadId":"11903","inReplyTo":"20080205211044.GP26392-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org","subject":"Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-02-05T22:21:58Z","receivedAt":"2008-02-05T22:21:58Z","isPatch":true,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Tue, 5 Feb 2008, Brian Downing wrote:\n\n> diff --git a/compat/qsort.c b/compat/qsort.c\n> new file mode 100644\n> index 0000000..8663889\n> --- /dev/null\n> +++ b/compat/qsort.c\n> @@ -0,0 +1,60 @@\n> +#include \"../git-compat-util.h\"\n> +\n> +/* This merge sort implementation is simplified from glibc's. */\n> +static void msort_with_tmp(void *b, size_t n, size_t s,\n\nDidn't you forget to include the original copyright, as well as yours?\n\nBTW if these 60 lines have code that is really faster than Microsoft's \nimplementation of a sort, it is really fascinating to me.\n\nCiao,\nDscho\n"},{"id":"67606","messageId":"20080206024732.GR26392@lavos.net","threadId":"11903","inReplyTo":"alpine.LSU.1.00.0802052220500.8543-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org","subject":"Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc","fromName":"Brian Downing","fromEmail":"bdowning-ou/tddhfglreowh0uzbu5w@public.gmane.org","sentAt":"2008-02-06T02:47:32Z","receivedAt":"2008-02-06T02:47:32Z","isPatch":true,"sender":{"key":"bdowning-ou/tddhfglreowh0uzbu5w@public.gmane.org","avatar":null},"body":"\nOn Tue, Feb 05, 2008 at 10:21:58PM +0000, Johannes Schindelin wrote:\n> On Tue, 5 Feb 2008, Brian Downing wrote:\n> > diff --git a/compat/qsort.c b/compat/qsort.c\n> > new file mode 100644\n> > index 0000000..8663889\n> > --- /dev/null\n> > +++ b/compat/qsort.c\n> > @@ -0,0 +1,60 @@\n> > +#include \"../git-compat-util.h\"\n> > +\n> > +/* This merge sort implementation is simplified from glibc's. */\n> > +static void msort_with_tmp(void *b, size_t n, size_t s,\n> \n> Didn't you forget to include the original copyright, as well as yours?\n\nI (perhaps naïvely) assumed the \"from glibc\" would be enough. If not,\nthe original is:\n\n/* An alternative to qsort, with an identical interface.\n This file is part of the GNU C Library.\n Copyright (C) 1992,95-97,99,2000,01,02,04 Free Software Foundation, Inc.\n Written by Mike Haertel, September 1988.\n\n The GNU C Library is free software; you can redistribute it and/or\n modify it under the terms of the GNU Lesser General Public\n License as published by the Free Software Foundation; either\n version 2.1 of the License, or (at your option) any later version.\n\n The GNU C Library is distributed in the hope that it will be useful,\n but WITHOUT ANY WARRANTY; without even the implied warranty of\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n Lesser General Public License for more details.\n\n You should have received a copy of the GNU Lesser General Public\n License along with the GNU C Library; if not, write to the Free\n Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA\n 02111-1307 USA. */\n\n(That was from glibc-2.3.6/stdlib/msort.c. I'm not sure of the exact\nversion I referenced for the implementation, but it was a lot closer to\n2.3.6 than the current 2.7.)\n\nAs far as my copyleft, I was just planning on it being under Git's\nblanket copyleft. I really only pruned and reformatted code; there's\nreally nothing substantial to claim ownership of.\n\n> BTW if these 60 lines have code that is really faster than Microsoft's \n> implementation of a sort, it is really fascinating to me.\n\nWell, it's faster for us, but I bet our (usually mostly-sorted) tree\ninput is just better for a sort like a merge sort rather than a\nquicksort.\n\n-bcd\n"},{"id":"67746","messageId":"7vodatqu6w.fsf@gitster.siamese.dyndns.org","threadId":"11903","inReplyTo":"20080205211044.GP26392@lavos.net","subject":"Applying patches from gmane can be dangerous.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-07T04:14:31Z","receivedAt":"2008-02-07T04:14:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I picked up the qsort patch from Brian while reading the list\nvia gmane's newsfeed and applied it without realizing that it\nwas one of the articles whose addresses on all the address\nheader fields _and_ all strings that look like e-mail addresses\nhave been mangled by gmane. Sign-offs by Dscho and Steffen\nProhaska have also been munged (even though that are not part of\nheaders).\n\nIt already is part of 'next', and we have the policy of not\nrewinding 'next', so the record of this mistake will\nunfortunately be with us forever. Sorry, Brian, Dscho and\nSteffen.\n\nFor the curious, the message was:\n\n http://article.gmane.org/gmane.comp.version-control.git/72699/raw\n\nI've added the following in my .git/hooks/applypatch-msg and\nmade it executable, so hopefully it won't happen again.\n\n #!/bin/sh\n case \"$GIT_AUTHOR_EMAIL\" in\n *@public.gmane.org)\n echo >&2 \"Gmane munged the author's email address, aborting.\"\n echo >&2 \"Pick up the original message from your mbox!\"\n exit 1\n ;;\n esac\n\nThis is really sad. gmane gives us a clean threaded interface\n(both in web and newsreader), and it never forgets. Whenever I\nneed to refer somebody to an old discussion, I can give an URL\nto it and allmost all the discussion messages are there with a\nsingle paste and clicking around. It has been an indispensable\nservice to me ever since I started reading the git list with it.\nIt is really a shame that I have to prevent picking up patch\nmessages from it with the above hook.\n\nI am wondering if other development communities had a similar\nissue already, and if so how they are dealing with it.\n"},{"id":"67748","messageId":"alpine.LFD.1.00.0802062327350.2732@xanadu.home","threadId":"11903","inReplyTo":"7vodatqu6w.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-07T04:29:12Z","receivedAt":"2008-02-07T04:29:12Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 6 Feb 2008, Junio C Hamano wrote:\n\n> I picked up the qsort patch from Brian while reading the list\n> via gmane's newsfeed and applied it without realizing that it\n> was one of the articles whose addresses on all the address\n> header fields _and_ all strings that look like e-mail addresses\n> have been mangled by gmane. Sign-offs by Dscho and Steffen\n> Prohaska have also been munged (even though that are not part of\n> headers).\n> \n> It already is part of 'next', and we have the policy of not\n> rewinding 'next', so the record of this mistake will\n> unfortunately be with us forever. Sorry, Brian, Dscho and\n> Steffen.\n\nMaybe you can make an exception for this time? A single\n\n\nNicolas\n"},{"id":"67763","messageId":"ve51w5yb.fsf@blue.sea.net","threadId":"11903","inReplyTo":"7vodatqu6w.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-07T08:01:32Z","receivedAt":"2008-02-07T08:01:32Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Wed 2008-02-06 Junio C Hamano \n* Message-Id: 7vodatqu6w.fsf@gitster.siamese.dyndns.org\n> I picked up the qsort patch from Brian while reading the list\n> via gmane's newsfeed and applied it without realizing that it\n> was one of the articles whose addresses on all the address\n> header fields _and_ all strings that look like e-mail addresses\n> have been mangled by gmane. Sign-offs by Dscho and Steffen\n\nFYI,\n\nEmacs Gnus + news.gmane.org gives access to raw articles with single\ncommand. Suppose cursor is at thread start \"!\"\n\n! R. [ 40: Junio C Hamano ] Applying patches from gmane can be dangerous.\n R. [ 19: Nicolas Pitre ]\n\n\nPressing \"C-u g\" will display the unmodified article as seen by mail\ntransport. Running git's apply command can be automated pretty easily\nfrom there.\n\nJari\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"67765","messageId":"7vsl05p46n.fsf@gitster.siamese.dyndns.org","threadId":"11903","inReplyTo":"ve51w5yb.fsf@blue.sea.net","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-07T08:21:36Z","receivedAt":"2008-02-07T08:21:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jari Aalto writes:\n\n> FYI,\n>\n> Emacs Gnus + news.gmane.org gives access to raw articles with single\n> command. Suppose cursor is at thread start \"!\"\n>\n> ! R. [ 40: Junio C Hamano ] Applying patches from gmane can be dangerous.\n> R. [ 19: Nicolas Pitre ]\n>\n>\n> Pressing \"C-u g\" will display the unmodified article as seen by mail\n> transport. Running git's apply command can be automated pretty easily\n> from there.\n\nI do not think Gnus demiming (that C-u g helps us with) is not\nan issue.\n\nHave you tried to look at the article in question? Inside your\nGnus + news.gmane.org, try typing this:\n\n\tj 7 2 6 9 9 C-u g\n\nThe last two keystrokes are your \"C-u g\".\n\nAnd look at the second line in the buffer, that says:\n\n From: Brian Downing \n\nand weep X-<.\n\nThen scroll down to find Signed-off-by: lines that are similarly\nmangled, and weep more.\n\nMaybe you run a much newer Gnus, and Lars taught \"C-u g\" to\nunmangle them. After all, gmane and Gnus are both his\ncreations, so it _is_ possible. But somehow I doubt it.\n\nIf there weren't gmane address mangling, a quickest way to apply\na gmane patch to commit is:\n\n\tC-u g | g i t a m - 3 - s \n\n\tFor Gnus uninitiated, it reads: show as raw as opposed\n\tto demimed (C-u g), pipe the article to the shell\n\tcommand (|) that is \"git am -3 -s\".\n\nBut I usually work in batches, so I first C-o (write to file)\nthe articles to a separate mbox, review and _edit_ them as\nneeded before running \"git am\". And C-o does not suffer from\nGnus demiming, so C-u g is not useful in my workflow.\n"},{"id":"67768","messageId":"20080207090500.GA2296@glandium.org","threadId":"11903","inReplyTo":"7vsl05p46n.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-02-07T09:05:01Z","receivedAt":"2008-02-07T09:05:01Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Feb 07, 2008 at 12:21:36AM -0800, Junio C Hamano wrote:\n> Maybe you run a much newer Gnus, and Lars taught \"C-u g\" to\n> unmangle them. After all, gmane and Gnus are both his\n> creations, so it _is_ possible. But somehow I doubt it.\n\nIf that can be unmangled, what would be the purpose of mangling in the first\nplace ? If the mangling is any useful, it can't be unmangled. If it can, it\nshould just be removed.\n\nMike\n"},{"id":"67769","messageId":"7vy79xnnfq.fsf@gitster.siamese.dyndns.org","threadId":"11903","inReplyTo":"alpine.LFD.1.00.0802062327350.2732@xanadu.home","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-07T09:08:41Z","receivedAt":"2008-02-07T09:08:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 6 Feb 2008, Junio C Hamano wrote:\n>\n>> ...\n>> It already is part of 'next', and we have the policy of not\n>> rewinding 'next', so the record of this mistake will\n>> unfortunately be with us forever. Sorry, Brian, Dscho and\n>> Steffen.\n>\n> Maybe you can make an exception for this time? A single\n\nThat's very tempting.\n\nThere currently are 1176 commits in 'next' that are not in\n'master'. Among them, 1100 or so of them will never be. They\nare merges of topics that have long graduated to 'master', or\nupmerge of 'master' into 'next'.\n\nIf we rebuild an equivalent of 'next', starting with 'master'\nand merging the still-cooking topics today, the result is only\n70 commits ahead of 'master'. Among of them, 16 are merges.\n\nIn other words, 'next' will go down from v1.5.4-1200-gXXXXXX to\nv1.5.4-70-gXXXXXX all of a sudden, if we decide to do so.\n\nPeople who follow 'next' hopefully know what goes on the list,\nso perhaps we could revise the \"never rewind\" rule to read \"it\nwill not rewind during the regular cycle, but it will be rebuilt\nonce each feature release, immediately after release.\"\n\nHmmmmmmmm...\n"},{"id":"67786","messageId":"alpine.LSU.1.00.0802071241210.8543@racer.site","threadId":"11903","inReplyTo":"7vsl05p46n.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-07T12:42:19Z","receivedAt":"2008-02-07T12:42:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Feb 2008, Junio C Hamano wrote:\n\n> Jari Aalto writes:\n> \n> > Emacs Gnus + news.gmane.org gives access to raw articles with single\n> > command.\n>\n> Maybe you run a much newer Gnus, and Lars taught \"C-u g\" to unmangle \n> them. After all, gmane and Gnus are both his creations, so it _is_ \n> possible. But somehow I doubt it.\n\nAnd because he was culled from the Cc: list, he will miss this discussion.\n\nThanks,\nDscho\n"},{"id":"67800","messageId":"20080207133208.GT26392@lavos.net","threadId":"11903","inReplyTo":"7vodatqu6w.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2008-02-07T13:32:08Z","receivedAt":"2008-02-07T13:32:08Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:\n> This is really sad. gmane gives us a clean threaded interface\n> (both in web and newsreader), and it never forgets. Whenever I\n> need to refer somebody to an old discussion, I can give an URL\n> to it and allmost all the discussion messages are there with a\n> single paste and clicking around. It has been an indispensable\n> service to me ever since I started reading the git list with it.\n> It is really a shame that I have to prevent picking up patch\n> messages from it with the above hook.\n> \n> I am wondering if other development communities had a similar\n> issue already, and if so how they are dealing with it.\n\nGmane didn't start doing this until recently. Maybe they can stop it on\na group-by-group basis? Every post to git@vger is archived elsewhere\nwith unmangled email addresses anyway...\n\n\"We understand why you're doing this, but it hurts us greatly. Please\nstop.\"\n\n-bcd\n"},{"id":"67808","messageId":"20080207141004.GB18497@mail-vs.djpig.de","threadId":"11903","inReplyTo":"7vodatqu6w.fsf@gitster.siamese.dyndns.org","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Frank Lichtenheld","fromEmail":"frank@lichtenheld.de","sentAt":"2008-02-07T14:10:05Z","receivedAt":"2008-02-07T14:10:05Z","isPatch":false,"sender":{"key":"frank@lichtenheld.de","avatar":"https://gravatar.com/avatar/b9f1d4b120e138f157c9e480d0818197c474628923786adb98f30017cdb99c3c?d=mp&s=160"},"body":"On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:\n> I am wondering if other development communities had a similar\n> issue already, and if so how they are dealing with it.\n\nhttp://gmane.org/tmda.php suggests that this is a feature that can be\nturned off or on on a per-list basis. So maybe you just need to request\nto turn it off?\n\nGruesse,\n-- \nFrank Lichtenheld \nwww: http://www.djpig.de/\n"},{"id":"67809","messageId":"20080207145036.GM26016@yugib.highrise.ca","threadId":"11903","inReplyTo":"20080207133208.GT26392@lavos.net","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-02-07T14:50:36Z","receivedAt":"2008-02-07T14:50:36Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"* Brian Downing [080207 07:32]:\n> On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:\n> > This is really sad. gmane gives us a clean threaded interface\n> > (both in web and newsreader), and it never forgets. Whenever I\n> > need to refer somebody to an old discussion, I can give an URL\n> > to it and allmost all the discussion messages are there with a\n> > single paste and clicking around. It has been an indispensable\n> > service to me ever since I started reading the git list with it.\n> > It is really a shame that I have to prevent picking up patch\n> > messages from it with the above hook.\n> > \n> > I am wondering if other development communities had a similar\n> > issue already, and if so how they are dealing with it.\n> \n> Gmane didn't start doing this until recently. Maybe they can stop it on\n> a group-by-group basis? Every post to git@vger is archived elsewhere\n> with unmangled email addresses anyway...\n> \n> \"We understand why you're doing this, but it hurts us greatly. Please\n> stop.\"\n\nGmane has always done the \"hide the real email\" address on groups that\nrequest it. The git group does *not* request it, but the msysgit group\n*has* requested it.\n\nNote that I dont ahve any inner circle knowledge of gmane, but I have\nused it for ages, and watched the gmane discuss for as long.\n\nOne of the \"nice\" things about gmane is that it follows thread/lines/etc\nacross groups as the discussions move. They do this because the only\nstore a single copy of the message (based on message-id), and link it to\nthe groups (after all, it is a news store). But because of that single\ncopy of a message, if the 1st group/list a message comes in for is set\nto hide the email addresses, I beleve the stored copy gets its addresses\nmunged.\n\nIf you look at the message Junio referenced, it hit gmane first from the\nmsysgit list (@google), not the git list (@vger). So when the git@vger\nmail came in with the same message-id, it simply linked it to the\nalready stored message\n\nBasically, we have to convince groups that are commonly \"overlapping\"\ngit@vger on gmane not to choose hiding the emails. In this case, the\nmsysgit group.\n\na.\n\n-- \nAidan Van Dyk Create like a god,\naidan@highrise.ca command like a king,\nhttp://www.highrise.ca/ work like a slave.\n"},{"id":"67812","messageId":"20080207150306.GU26392@lavos.net","threadId":"11903","inReplyTo":"20080207145036.GM26016@yugib.highrise.ca","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2008-02-07T15:03:06Z","receivedAt":"2008-02-07T15:03:06Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Thu, Feb 07, 2008 at 09:50:36AM -0500, Aidan Van Dyk wrote:\n> If you look at the message Junio referenced, it hit gmane first from the\n> msysgit list (@google), not the git list (@vger). So when the git@vger\n> mail came in with the same message-id, it simply linked it to the\n> already stored message\n> \n> Basically, we have to convince groups that are commonly \"overlapping\"\n> git@vger on gmane not to choose hiding the emails. In this case, the\n> msysgit group.\n\nThanks, that clears things up for me.\n\n-bcd\n"},{"id":"67816","messageId":"alpine.LSU.1.00.0802071605540.8543@racer.site","threadId":"11903","inReplyTo":"20080207145036.GM26016@yugib.highrise.ca","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-07T16:10:01Z","receivedAt":"2008-02-07T16:10:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Feb 2008, Aidan Van Dyk wrote:\n\n> * Brian Downing [080207 07:32]:\n> > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:\n> > > This is really sad. gmane gives us a clean threaded interface\n> > > (both in web and newsreader), and it never forgets. Whenever I\n> > > need to refer somebody to an old discussion, I can give an URL\n> > > to it and allmost all the discussion messages are there with a\n> > > single paste and clicking around. It has been an indispensable\n> > > service to me ever since I started reading the git list with it.\n> > > It is really a shame that I have to prevent picking up patch\n> > > messages from it with the above hook.\n> > > \n> > > I am wondering if other development communities had a similar\n> > > issue already, and if so how they are dealing with it.\n> > \n> > Gmane didn't start doing this until recently. Maybe they can stop it on\n> > a group-by-group basis? Every post to git@vger is archived elsewhere\n> > with unmangled email addresses anyway...\n> > \n> > \"We understand why you're doing this, but it hurts us greatly. Please\n> > stop.\"\n> \n> Gmane has always done the \"hide the real email\" address on groups that\n> request it. The git group does *not* request it, but the msysgit group\n> *has* requested it.\n\nI just requested this setting to be changed. Will keep you posted.\n\nThanks,\nDscho\n"},{"id":"68190","messageId":"7vfxw1gk3i.fsf@gitster.siamese.dyndns.org","threadId":"11903","inReplyTo":"7vy79xnnfq.fsf@gitster.siamese.dyndns.org","subject":"'next' will be rewound and rebuilt after feature releases.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-10T10:51:45Z","receivedAt":"2008-02-10T10:51:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nicolas Pitre writes:\n>\n>> On Wed, 6 Feb 2008, Junio C Hamano wrote:\n>>\n>>> ...\n>>> It already is part of 'next', and we have the policy of not\n>>> rewinding 'next', so the record of this mistake will\n>>> unfortunately be with us forever. Sorry, Brian, Dscho and\n>>> Steffen.\n>>\n>> Maybe you can make an exception for this time? A single\n>\n> That's very tempting.\n> ...\n> People who follow 'next' hopefully know what goes on the list,\n> so perhaps we could revise the \"never rewind\" rule to read \"it\n> will not rewind during the regular cycle, but it will be rebuilt\n> once each feature release, immediately after release.\"\n\nI am almost committed to this idea, and this is an advance\nnotice that 'next' will be rebuilt on the tip of 'master' soon.\n\nWhen that happens, I'll announce the commit object name for the\nold 'next' and the corresponding new one, to make rebasing\neasier for people who have been following and building on top of\nit.\n\nFor tonight's tree, the tip of 'next' is at 547b1cb (Merge\nbranch 'master' into next) and its tree matches 26f14cc (Merge\nbranch 'js/reflog-delete' into next) that is part of 'pu'.\n"},{"id":"68442","messageId":"alpine.LSU.1.00.0802112115590.3870@racer.site","threadId":"11903","inReplyTo":"alpine.LSU.1.00.0802071605540.8543@racer.site","subject":"Re: Applying patches from gmane can be dangerous.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-11T21:16:57Z","receivedAt":"2008-02-11T21:16:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Feb 2008, Johannes Schindelin wrote:\n\n> On Thu, 7 Feb 2008, Aidan Van Dyk wrote:\n> \n> > * Brian Downing [080207 07:32]:\n> > > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:\n> > > > This is really sad. gmane gives us a clean threaded interface\n> > > > (both in web and newsreader), and it never forgets. Whenever I\n> > > > need to refer somebody to an old discussion, I can give an URL\n> > > > to it and allmost all the discussion messages are there with a\n> > > > single paste and clicking around. It has been an indispensable\n> > > > service to me ever since I started reading the git list with it.\n> > > > It is really a shame that I have to prevent picking up patch\n> > > > messages from it with the above hook.\n> > > > \n> > > > I am wondering if other development communities had a similar\n> > > > issue already, and if so how they are dealing with it.\n> > > \n> > > Gmane didn't start doing this until recently. Maybe they can stop it on\n> > > a group-by-group basis? Every post to git@vger is archived elsewhere\n> > > with unmangled email addresses anyway...\n> > > \n> > > \"We understand why you're doing this, but it hurts us greatly. Please\n> > > stop.\"\n> > \n> > Gmane has always done the \"hide the real email\" address on groups that\n> > request it. The git group does *not* request it, but the msysgit group\n> > *has* requested it.\n> \n> I just requested this setting to be changed. Will keep you posted.\n\nOkay, this took a while, basically, because I am not registered as a \"list \nadmin\" at gmane.\n\nBut Abdel, who is, sorted out the problems, and we will no longer have \nthis issue.\n\nThanks for your attention,\nDscho\n"}]}