Applying patches from gmane can be dangerous.

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.

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

* Wed 2008-02-06 Junio C Hamano [off-list ref]
* 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

Nicolas Pitre [off-list ref] writes:

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

quoted

...
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...

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

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 [off-list ref]
www: http://www.djpig.de/

* Brian Downing [off-list ref] [080207 07:32]:

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:

quoted

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.

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

Hi,

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

* Brian Downing [off-list ref] [080207 07:32]:

quoted

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:

quoted

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

Junio C Hamano [off-list ref] writes:

Nicolas Pitre [off-list ref] writes:

quoted

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

quoted

...
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'.

Hi,

On Thu, 7 Feb 2008, Johannes Schindelin wrote:

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

quoted

* Brian Downing [off-list ref] [080207 07:32]:

quoted

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:

quoted

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