All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] compat: Add simplified merge sort implementation from glibc
@ 2008-02-05 21:10 Brian Downing
       [not found] ` <20080205211044.GP26392-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
  2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
  0 siblings, 2 replies; 17+ messages in thread
From: Brian Downing @ 2008-02-05 21:10 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw,
	Edgar Toernig, Steffen Prohaska, Johannes Schindelin


qsort in Windows 2000 (and various other C libraries) is a Quicksort
with the usual O(n^2) worst case.  Unfortunately, sorting Git trees
seems to get very close to that worst case quite often:

    $ /git/gitbad runstatus
    # On branch master
    qsort, nmemb = 30842
    done, 237838087 comparisons.

This patch adds a simplified version of the merge sort that is glibc's
qsort(3).  As a merge sort, this needs a temporary array equal in size
to the array that is to be sorted, but has a worst-case performance of
O(n log n).

The complexity that was removed is:

* Doing direct stores for word-size and -aligned data.
* Falling back to quicksort if the allocation required to perform the
  merge sort would likely push the machine into swap.

Even with these simplifications, this seems to outperform the Windows
qsort(3) implementation, even in Windows XP (where it is "fixed" and
doesn't trigger O(n^2) complexity on trees).

[jes: moved into compat/qsort.c, as per Johannes Sixt's suggestion]
[bcd: removed gcc-ism, thanks to Edgar Toernig.  renamed make variable
      per Junio's comment.]

Signed-off-by: Brian Downing <bdowning-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
Signed-off-by: Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin-Mmb7MZpHnFY@public.gmane.org>
---
    Here it is again.  Sorry about the mail screwup.

    -bcd

 Makefile          |    9 ++++++++
 compat/qsort.c    |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 git-compat-util.h |    6 +++++
 3 files changed, 75 insertions(+), 0 deletions(-)
 create mode 100644 compat/qsort.c

diff --git a/Makefile b/Makefile
index 92341c4..a0e5c0c 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,11 @@ all::
 # Define THREADED_DELTA_SEARCH if you have pthreads and wish to exploit
 # parallel delta searching when packing objects.
 #
+# Define INTERNAL_QSORT to use Git's implementation of qsort(), which
+# is a simplified version of the merge sort used in glibc. This is
+# recommended if Git triggers O(n^2) complexity in your
+# implementation's qsort().
+#
 
 GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -722,6 +727,10 @@ ifdef NO_MEMMEM
 	COMPAT_CFLAGS += -DNO_MEMMEM
 	COMPAT_OBJS += compat/memmem.o
 endif
+ifdef INTERNAL_QSORT
+	COMPAT_CFLAGS += -DINTERNAL_QSORT
+	COMPAT_OBJS += compat/qsort.o
+endif
 
 ifdef THREADED_DELTA_SEARCH
 	BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
diff --git a/compat/qsort.c b/compat/qsort.c
new file mode 100644
index 0000000..8663889
--- /dev/null
+++ b/compat/qsort.c
@@ -0,0 +1,60 @@
+#include "../git-compat-util.h"
+
+/* This merge sort implementation is simplified from glibc's. */
+static void msort_with_tmp(void *b, size_t n, size_t s,
+			   int (*cmp)(const void *, const void *),
+			   char *t)
+{
+	char *tmp;
+	char *b1, *b2;
+	size_t n1, n2;
+
+	if (n <= 1)
+		return;
+
+	n1 = n / 2;
+	n2 = n - n1;
+	b1 = b;
+	b2 = (char *)b + (n1 * s);
+
+	msort_with_tmp(b1, n1, s, cmp, t);
+	msort_with_tmp(b2, n2, s, cmp, t);
+
+	tmp = t;
+
+	while (n1 > 0 && n2 > 0) {
+		if (cmp(b1, b2) <= 0) {
+			memcpy(tmp, b1, s);
+			tmp += s;
+			b1 += s;
+			--n1;
+		} else {
+			memcpy(tmp, b2, s);
+			tmp += s;
+			b2 += s;
+			--n2;
+		}
+	}
+	if (n1 > 0)
+		memcpy(tmp, b1, n1 * s);
+	memcpy(b, t, (n - n2) * s);
+}
+
+void git_qsort(void *b, size_t n, size_t s,
+	       int (*cmp)(const void *, const void *))
+{
+	const size_t size = n * s;
+
+	if (size < 1024) {
+		char buf[1024];
+
+		/* The temporary array is small, so put it on
+		   the stack.  */
+		msort_with_tmp(b, n, s, cmp, buf);
+	} else {
+		/* It's somewhat large, so malloc it.  */
+		char *tmp = malloc(size);
+		msort_with_tmp(b, n, s, cmp, tmp);
+		free(tmp);
+	}
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 4df90cb..0514604 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -426,4 +426,10 @@ static inline int strtol_i(char const *s, int base, int *result)
 	return 0;
 }
 
+#ifdef INTERNAL_QSORT
+void git_qsort(void *base, size_t nmemb, size_t size,
+	       int(*compar)(const void *, const void *));
+#define qsort git_qsort
+#endif
+
 #endif
-- 
1.5.4.rc3

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc
       [not found] ` <20080205211044.GP26392-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
@ 2008-02-05 22:21   ` Johannes Schindelin
       [not found]     ` <alpine.LSU.1.00.0802052220500.8543-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Johannes Schindelin @ 2008-02-05 22:21 UTC (permalink / raw)
  To: Brian Downing
  Cc: Junio C Hamano, git-u79uwXL29TY76Z2rM5mHXA,
	msysgit-/JYPxA39Uh5TLH3MbocFFw, Edgar Toernig, Steffen Prohaska


Hi,

On Tue, 5 Feb 2008, Brian Downing wrote:

> diff --git a/compat/qsort.c b/compat/qsort.c
> new file mode 100644
> index 0000000..8663889
> --- /dev/null
> +++ b/compat/qsort.c
> @@ -0,0 +1,60 @@
> +#include "../git-compat-util.h"
> +
> +/* This merge sort implementation is simplified from glibc's. */
> +static void msort_with_tmp(void *b, size_t n, size_t s,

Didn't you forget to include the original copyright, as well as yours?

BTW if these 60 lines have code that is really faster than Microsoft's 
implementation of a sort, it is really fascinating to me.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc
       [not found]     ` <alpine.LSU.1.00.0802052220500.8543-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
@ 2008-02-06  2:47       ` Brian Downing
  0 siblings, 0 replies; 17+ messages in thread
From: Brian Downing @ 2008-02-06  2:47 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Junio C Hamano, git-u79uwXL29TY76Z2rM5mHXA,
	msysgit-/JYPxA39Uh5TLH3MbocFFw, Edgar Toernig, Steffen Prohaska


On Tue, Feb 05, 2008 at 10:21:58PM +0000, Johannes Schindelin wrote:
> On Tue, 5 Feb 2008, Brian Downing wrote:
> > diff --git a/compat/qsort.c b/compat/qsort.c
> > new file mode 100644
> > index 0000000..8663889
> > --- /dev/null
> > +++ b/compat/qsort.c
> > @@ -0,0 +1,60 @@
> > +#include "../git-compat-util.h"
> > +
> > +/* This merge sort implementation is simplified from glibc's. */
> > +static void msort_with_tmp(void *b, size_t n, size_t s,
> 
> Didn't you forget to include the original copyright, as well as yours?

I (perhaps naïvely) assumed the "from glibc" would be enough.  If not,
the original is:

/* An alternative to qsort, with an identical interface.
   This file is part of the GNU C Library.
   Copyright (C) 1992,95-97,99,2000,01,02,04 Free Software Foundation, Inc.
   Written by Mike Haertel, September 1988.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, write to the Free
   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
   02111-1307 USA.  */

(That was from glibc-2.3.6/stdlib/msort.c.  I'm not sure of the exact
version I referenced for the implementation, but it was a lot closer to
2.3.6 than the current 2.7.)

As far as my copyleft, I was just planning on it being under Git's
blanket copyleft.  I really only pruned and reformatted code; there's
really nothing substantial to claim ownership of.

> BTW if these 60 lines have code that is really faster than Microsoft's 
> implementation of a sort, it is really fascinating to me.

Well, it's faster for us, but I bet our (usually mostly-sorted) tree
input is just better for a sort like a merge sort rather than a
quicksort.

-bcd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Applying patches from gmane can be dangerous.
  2008-02-05 21:10 [PATCH v2] compat: Add simplified merge sort implementation from glibc Brian Downing
       [not found] ` <20080205211044.GP26392-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
@ 2008-02-07  4:14 ` Junio C Hamano
  2008-02-07  4:29   ` Nicolas Pitre
                     ` (3 more replies)
  1 sibling, 4 replies; 17+ messages in thread
From: Junio C Hamano @ 2008-02-07  4:14 UTC (permalink / raw)
  To: git; +Cc: Brian Downing, Johannes Schindelin, Lars Magne Ingebrigtsen

I picked up the qsort patch from Brian while reading the list
via gmane's newsfeed and applied it without realizing that it
was one of the articles whose addresses on all the address
header fields _and_ all strings that look like e-mail addresses
have been mangled by gmane.  Sign-offs by Dscho and Steffen
Prohaska have also been munged (even though that are not part of
headers).

It already is part of 'next', and we have the policy of not
rewinding 'next', so the record of this mistake will
unfortunately be with us forever.  Sorry, Brian, Dscho and
Steffen.

For the curious, the message was:

    http://article.gmane.org/gmane.comp.version-control.git/72699/raw

I've added the following in my .git/hooks/applypatch-msg and
made it executable, so hopefully it won't happen again.

    #!/bin/sh
    case "$GIT_AUTHOR_EMAIL" in
    *@public.gmane.org)
            echo >&2 "Gmane munged the author's email address, aborting."
            echo >&2 "Pick up the original message from your mbox!"
            exit 1
            ;;
    esac

This is really sad.  gmane gives us a clean threaded interface
(both in web and newsreader), and it never forgets. Whenever I
need to refer somebody to an old discussion, I can give an URL
to it and allmost all the discussion messages are there with a
single paste and clicking around.  It has been an indispensable
service to me ever since I started reading the git list with it.
It is really a shame that I have to prevent picking up patch
messages from it with the above hook.

I am wondering if other development communities had a similar
issue already, and if so how they are dealing with it.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
@ 2008-02-07  4:29   ` Nicolas Pitre
  2008-02-07  9:08     ` Junio C Hamano
  2008-02-07  8:01   ` Applying patches from gmane can be dangerous Jari Aalto
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 17+ messages in thread
From: Nicolas Pitre @ 2008-02-07  4:29 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Brian Downing, Johannes Schindelin, Lars Magne Ingebrigtsen

On Wed, 6 Feb 2008, Junio C Hamano wrote:

> I picked up the qsort patch from Brian while reading the list
> via gmane's newsfeed and applied it without realizing that it
> was one of the articles whose addresses on all the address
> header fields _and_ all strings that look like e-mail addresses
> have been mangled by gmane.  Sign-offs by Dscho and Steffen
> Prohaska have also been munged (even though that are not part of
> headers).
> 
> It already is part of 'next', and we have the policy of not
> rewinding 'next', so the record of this mistake will
> unfortunately be with us forever.  Sorry, Brian, Dscho and
> Steffen.

Maybe you can make an exception for this time?  A single


Nicolas

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
  2008-02-07  4:29   ` Nicolas Pitre
@ 2008-02-07  8:01   ` Jari Aalto
  2008-02-07  8:21     ` Junio C Hamano
  2008-02-07 13:32   ` Brian Downing
  2008-02-07 14:10   ` Frank Lichtenheld
  3 siblings, 1 reply; 17+ messages in thread
From: Jari Aalto @ 2008-02-07  8:01 UTC (permalink / raw)
  To: git

* Wed 2008-02-06 Junio C Hamano <gitster@pobox.com>
* Message-Id: 7vodatqu6w.fsf@gitster.siamese.dyndns.org
> I picked up the qsort patch from Brian while reading the list
> via gmane's newsfeed and applied it without realizing that it
> was one of the articles whose addresses on all the address
> header fields _and_ all strings that look like e-mail addresses
> have been mangled by gmane.  Sign-offs by Dscho and Steffen

FYI,

Emacs Gnus + news.gmane.org gives access to raw articles with single
command. Suppose cursor is at thread start "!"

! R. [  40: Junio C Hamano         ] Applying patches from gmane can be dangerous.
  R.     [  19: Nicolas Pitre          ]


Pressing "C-u g" will display the unmodified article as seen by mail
transport. Running git's apply command can be automated pretty easily
from there.

Jari

-- 
Welcome to FOSS revolution: we fix and modify until it shines

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  8:01   ` Applying patches from gmane can be dangerous Jari Aalto
@ 2008-02-07  8:21     ` Junio C Hamano
  2008-02-07  9:05       ` Mike Hommey
  2008-02-07 12:42       ` Johannes Schindelin
  0 siblings, 2 replies; 17+ messages in thread
From: Junio C Hamano @ 2008-02-07  8:21 UTC (permalink / raw)
  To: Jari Aalto; +Cc: git

Jari Aalto <jari.aalto@cante.net> writes:

> FYI,
>
> Emacs Gnus + news.gmane.org gives access to raw articles with single
> command. Suppose cursor is at thread start "!"
>
> ! R. [  40: Junio C Hamano         ] Applying patches from gmane can be dangerous.
>   R.     [  19: Nicolas Pitre          ]
>
>
> Pressing "C-u g" will display the unmodified article as seen by mail
> transport. Running git's apply command can be automated pretty easily
> from there.

I do not think Gnus demiming (that C-u g helps us with) is not
an issue.

Have you tried to look at the article in question?  Inside your
Gnus + news.gmane.org, try typing this:

	j 7 2 6 9 9 <Enter> C-u g

The last two keystrokes are your "C-u g".

And look at the second line in the buffer, that says:

    From: Brian Downing <bdowning-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>

and weep X-<.

Then scroll down to find Signed-off-by: lines that are similarly
mangled, and weep more.

Maybe you run a much newer Gnus, and Lars taught "C-u g" to
unmangle them.  After all, gmane and Gnus are both his
creations, so it _is_ possible.  But somehow I doubt it.

If there weren't gmane address mangling, a quickest way to apply
a gmane patch to commit is:

	C-u g | g i t  a m - 3 - s <Enter>

	For Gnus uninitiated, it reads: show as raw as opposed
	to demimed (C-u g), pipe the article to the shell
	command (|) that is "git am -3 -s".

But I usually work in batches, so I first C-o (write to file)
the articles to a separate mbox, review and _edit_ them as
needed before running "git am".  And C-o does not suffer from
Gnus demiming, so C-u g is not useful in my workflow.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  8:21     ` Junio C Hamano
@ 2008-02-07  9:05       ` Mike Hommey
  2008-02-07 12:42       ` Johannes Schindelin
  1 sibling, 0 replies; 17+ messages in thread
From: Mike Hommey @ 2008-02-07  9:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jari Aalto, git

On Thu, Feb 07, 2008 at 12:21:36AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Maybe you run a much newer Gnus, and Lars taught "C-u g" to
> unmangle them.  After all, gmane and Gnus are both his
> creations, so it _is_ possible.  But somehow I doubt it.

If that can be unmangled, what would be the purpose of mangling in the first
place ? If the mangling is any useful, it can't be unmangled. If it can, it
should just be removed.

Mike

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  4:29   ` Nicolas Pitre
@ 2008-02-07  9:08     ` Junio C Hamano
  2008-02-10 10:51       ` 'next' will be rewound and rebuilt after feature releases Junio C Hamano
  0 siblings, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2008-02-07  9:08 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Brian Downing, Johannes Schindelin

Nicolas Pitre <nico@cam.org> writes:

> On Wed, 6 Feb 2008, Junio C Hamano wrote:
>
>> ...
>> It already is part of 'next', and we have the policy of not
>> rewinding 'next', so the record of this mistake will
>> unfortunately be with us forever.  Sorry, Brian, Dscho and
>> Steffen.
>
> Maybe you can make an exception for this time?  A single

That's very tempting.

There currently are 1176 commits in 'next' that are not in
'master'.  Among them, 1100 or so of them will never be.  They
are merges of topics that have long graduated to 'master', or
upmerge of 'master' into 'next'.

If we rebuild an equivalent of 'next', starting with 'master'
and merging the still-cooking topics today, the result is only
70 commits ahead of 'master'.  Among of them, 16 are merges.

In other words, 'next' will go down from v1.5.4-1200-gXXXXXX to
v1.5.4-70-gXXXXXX all of a sudden, if we decide to do so.

People who follow 'next' hopefully know what goes on the list,
so perhaps we could revise the "never rewind" rule to read "it
will not rewind during the regular cycle, but it will be rebuilt
once each feature release, immediately after release."

Hmmmmmmmm...

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  8:21     ` Junio C Hamano
  2008-02-07  9:05       ` Mike Hommey
@ 2008-02-07 12:42       ` Johannes Schindelin
  1 sibling, 0 replies; 17+ messages in thread
From: Johannes Schindelin @ 2008-02-07 12:42 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jari Aalto, git

Hi,

On Thu, 7 Feb 2008, Junio C Hamano wrote:

> Jari Aalto <jari.aalto@cante.net> writes:
> 
> > Emacs Gnus + news.gmane.org gives access to raw articles with single
> > command.
>
> Maybe you run a much newer Gnus, and Lars taught "C-u g" to unmangle 
> them.  After all, gmane and Gnus are both his creations, so it _is_ 
> possible.  But somehow I doubt it.

And because he was culled from the Cc: list, he will miss this discussion.

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
  2008-02-07  4:29   ` Nicolas Pitre
  2008-02-07  8:01   ` Applying patches from gmane can be dangerous Jari Aalto
@ 2008-02-07 13:32   ` Brian Downing
  2008-02-07 14:50     ` Aidan Van Dyk
  2008-02-07 14:10   ` Frank Lichtenheld
  3 siblings, 1 reply; 17+ messages in thread
From: Brian Downing @ 2008-02-07 13:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin, Lars Magne Ingebrigtsen

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> This is really sad.  gmane gives us a clean threaded interface
> (both in web and newsreader), and it never forgets. Whenever I
> need to refer somebody to an old discussion, I can give an URL
> to it and allmost all the discussion messages are there with a
> single paste and clicking around.  It has been an indispensable
> service to me ever since I started reading the git list with it.
> It is really a shame that I have to prevent picking up patch
> messages from it with the above hook.
> 
> I am wondering if other development communities had a similar
> issue already, and if so how they are dealing with it.

Gmane didn't start doing this until recently.  Maybe they can stop it on
a group-by-group basis?  Every post to git@vger is archived elsewhere
with unmangled email addresses anyway...

"We understand why you're doing this, but it hurts us greatly.  Please
stop."

-bcd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
                     ` (2 preceding siblings ...)
  2008-02-07 13:32   ` Brian Downing
@ 2008-02-07 14:10   ` Frank Lichtenheld
  3 siblings, 0 replies; 17+ messages in thread
From: Frank Lichtenheld @ 2008-02-07 14:10 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Brian Downing, Johannes Schindelin, Lars Magne Ingebrigtsen

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> I am wondering if other development communities had a similar
> issue already, and if so how they are dealing with it.

http://gmane.org/tmda.php suggests that this is a feature that can be
turned off or on on a per-list basis. So maybe you just need to request
to turn it off?

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07 13:32   ` Brian Downing
@ 2008-02-07 14:50     ` Aidan Van Dyk
  2008-02-07 15:03       ` Brian Downing
  2008-02-07 16:10       ` Johannes Schindelin
  0 siblings, 2 replies; 17+ messages in thread
From: Aidan Van Dyk @ 2008-02-07 14:50 UTC (permalink / raw)
  To: Brian Downing
  Cc: Junio C Hamano, git, Johannes Schindelin, Lars Magne Ingebrigtsen

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

* Brian Downing <bdowning@lavos.net> [080207 07:32]:
> On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > This is really sad.  gmane gives us a clean threaded interface
> > (both in web and newsreader), and it never forgets. Whenever I
> > need to refer somebody to an old discussion, I can give an URL
> > to it and allmost all the discussion messages are there with a
> > single paste and clicking around.  It has been an indispensable
> > service to me ever since I started reading the git list with it.
> > It is really a shame that I have to prevent picking up patch
> > messages from it with the above hook.
> > 
> > I am wondering if other development communities had a similar
> > issue already, and if so how they are dealing with it.
> 
> Gmane didn't start doing this until recently.  Maybe they can stop it on
> a group-by-group basis?  Every post to git@vger is archived elsewhere
> with unmangled email addresses anyway...
> 
> "We understand why you're doing this, but it hurts us greatly.  Please
> stop."

Gmane has always done the "hide the real email" address on groups that
request it.  The git group does *not* request it, but the msysgit group
*has* requested it.

Note that I dont ahve any inner circle knowledge of gmane, but I have
used it for ages, and watched the gmane discuss for as long.

One of the "nice" things about gmane is that it follows thread/lines/etc
across groups as the discussions move.  They do this because the only
store a single copy of the message (based on message-id), and link it to
the groups  (after all, it is a news store).  But because of that single
copy of a message, if the 1st group/list a message comes in for is set
to hide the email addresses, I beleve the stored copy gets its addresses
munged.

If you look at the message Junio referenced, it hit gmane first from the
msysgit list (@google), not the git list (@vger).  So when the git@vger
mail came in with the same message-id, it simply linked it to the
already stored message

Basically, we have to convince groups that are commonly "overlapping"
git@vger on gmane not to choose hiding the emails.  In this case, the
msysgit group.

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07 14:50     ` Aidan Van Dyk
@ 2008-02-07 15:03       ` Brian Downing
  2008-02-07 16:10       ` Johannes Schindelin
  1 sibling, 0 replies; 17+ messages in thread
From: Brian Downing @ 2008-02-07 15:03 UTC (permalink / raw)
  To: Aidan Van Dyk
  Cc: Junio C Hamano, git, Johannes Schindelin, Lars Magne Ingebrigtsen

On Thu, Feb 07, 2008 at 09:50:36AM -0500, Aidan Van Dyk wrote:
> If you look at the message Junio referenced, it hit gmane first from the
> msysgit list (@google), not the git list (@vger).  So when the git@vger
> mail came in with the same message-id, it simply linked it to the
> already stored message
> 
> Basically, we have to convince groups that are commonly "overlapping"
> git@vger on gmane not to choose hiding the emails.  In this case, the
> msysgit group.

Thanks, that clears things up for me.

-bcd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07 14:50     ` Aidan Van Dyk
  2008-02-07 15:03       ` Brian Downing
@ 2008-02-07 16:10       ` Johannes Schindelin
  2008-02-11 21:16         ` Johannes Schindelin
  1 sibling, 1 reply; 17+ messages in thread
From: Johannes Schindelin @ 2008-02-07 16:10 UTC (permalink / raw)
  To: Aidan Van Dyk; +Cc: Brian Downing, Junio C Hamano, git, Lars Magne Ingebrigtsen

Hi,

On Thu, 7 Feb 2008, Aidan Van Dyk wrote:

> * Brian Downing <bdowning@lavos.net> [080207 07:32]:
> > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > > This is really sad.  gmane gives us a clean threaded interface
> > > (both in web and newsreader), and it never forgets. Whenever I
> > > need to refer somebody to an old discussion, I can give an URL
> > > to it and allmost all the discussion messages are there with a
> > > single paste and clicking around.  It has been an indispensable
> > > service to me ever since I started reading the git list with it.
> > > It is really a shame that I have to prevent picking up patch
> > > messages from it with the above hook.
> > > 
> > > I am wondering if other development communities had a similar
> > > issue already, and if so how they are dealing with it.
> > 
> > Gmane didn't start doing this until recently.  Maybe they can stop it on
> > a group-by-group basis?  Every post to git@vger is archived elsewhere
> > with unmangled email addresses anyway...
> > 
> > "We understand why you're doing this, but it hurts us greatly.  Please
> > stop."
> 
> Gmane has always done the "hide the real email" address on groups that
> request it.  The git group does *not* request it, but the msysgit group
> *has* requested it.

I just requested this setting to be changed.  Will keep you posted.

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 17+ messages in thread

* 'next' will be rewound and rebuilt after feature releases.
  2008-02-07  9:08     ` Junio C Hamano
@ 2008-02-10 10:51       ` Junio C Hamano
  0 siblings, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2008-02-10 10:51 UTC (permalink / raw)
  To: git; +Cc: Nicolas Pitre, Brian Downing, Johannes Schindelin

Junio C Hamano <gitster@pobox.com> writes:

> Nicolas Pitre <nico@cam.org> writes:
>
>> On Wed, 6 Feb 2008, Junio C Hamano wrote:
>>
>>> ...
>>> It already is part of 'next', and we have the policy of not
>>> rewinding 'next', so the record of this mistake will
>>> unfortunately be with us forever.  Sorry, Brian, Dscho and
>>> Steffen.
>>
>> Maybe you can make an exception for this time?  A single
>
> That's very tempting.
> ...
> People who follow 'next' hopefully know what goes on the list,
> so perhaps we could revise the "never rewind" rule to read "it
> will not rewind during the regular cycle, but it will be rebuilt
> once each feature release, immediately after release."

I am almost committed to this idea, and this is an advance
notice that 'next' will be rebuilt on the tip of 'master' soon.

When that happens, I'll announce the commit object name for the
old 'next' and the corresponding new one, to make rebasing
easier for people who have been following and building on top of
it.

For tonight's tree, the tip of 'next' is at 547b1cb (Merge
branch 'master' into next) and its tree matches 26f14cc (Merge
branch 'js/reflog-delete' into next) that is part of 'pu'.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Applying patches from gmane can be dangerous.
  2008-02-07 16:10       ` Johannes Schindelin
@ 2008-02-11 21:16         ` Johannes Schindelin
  0 siblings, 0 replies; 17+ messages in thread
From: Johannes Schindelin @ 2008-02-11 21:16 UTC (permalink / raw)
  To: Aidan Van Dyk
  Cc: Brian Downing, Junio C Hamano, git, Lars Magne Ingebrigtsen,
	Abdelrazak Younes

Hi,

On Thu, 7 Feb 2008, Johannes Schindelin wrote:

> On Thu, 7 Feb 2008, Aidan Van Dyk wrote:
> 
> > * Brian Downing <bdowning@lavos.net> [080207 07:32]:
> > > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > > > This is really sad.  gmane gives us a clean threaded interface
> > > > (both in web and newsreader), and it never forgets. Whenever I
> > > > need to refer somebody to an old discussion, I can give an URL
> > > > to it and allmost all the discussion messages are there with a
> > > > single paste and clicking around.  It has been an indispensable
> > > > service to me ever since I started reading the git list with it.
> > > > It is really a shame that I have to prevent picking up patch
> > > > messages from it with the above hook.
> > > > 
> > > > I am wondering if other development communities had a similar
> > > > issue already, and if so how they are dealing with it.
> > > 
> > > Gmane didn't start doing this until recently.  Maybe they can stop it on
> > > a group-by-group basis?  Every post to git@vger is archived elsewhere
> > > with unmangled email addresses anyway...
> > > 
> > > "We understand why you're doing this, but it hurts us greatly.  Please
> > > stop."
> > 
> > Gmane has always done the "hide the real email" address on groups that
> > request it.  The git group does *not* request it, but the msysgit group
> > *has* requested it.
> 
> I just requested this setting to be changed.  Will keep you posted.

Okay, this took a while, basically, because I am not registered as a "list 
admin" at gmane.

But Abdel, who is, sorted out the problems, and we will no longer have 
this issue.

Thanks for your attention,
Dscho

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2008-02-11 21:17 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-05 21:10 [PATCH v2] compat: Add simplified merge sort implementation from glibc Brian Downing
     [not found] ` <20080205211044.GP26392-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
2008-02-05 22:21   ` Johannes Schindelin
     [not found]     ` <alpine.LSU.1.00.0802052220500.8543-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
2008-02-06  2:47       ` Brian Downing
2008-02-07  4:14 ` Applying patches from gmane can be dangerous Junio C Hamano
2008-02-07  4:29   ` Nicolas Pitre
2008-02-07  9:08     ` Junio C Hamano
2008-02-10 10:51       ` 'next' will be rewound and rebuilt after feature releases Junio C Hamano
2008-02-07  8:01   ` Applying patches from gmane can be dangerous Jari Aalto
2008-02-07  8:21     ` Junio C Hamano
2008-02-07  9:05       ` Mike Hommey
2008-02-07 12:42       ` Johannes Schindelin
2008-02-07 13:32   ` Brian Downing
2008-02-07 14:50     ` Aidan Van Dyk
2008-02-07 15:03       ` Brian Downing
2008-02-07 16:10       ` Johannes Schindelin
2008-02-11 21:16         ` Johannes Schindelin
2008-02-07 14:10   ` Frank Lichtenheld

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.