On Sun, Aug 14, 2016 at 01:27:06AM +0000, Eric Wong wrote: > What's also interesting about the thread you highlighed is the > extra '<>' when you started that thread; and I have a bug where > I strip off an extra '>' which needs to be fixed... Oh, that's interesting. It's not in the message that started the thread; the bug is in the in-reply-to headers of the patches themselves. I don't remember what I was using to send patches back then. It might have been send-email, and I suspect I did: git send-email --in-reply-to='<whatever>' after cutting-and-pasting '<whatever>' from the cover letter. > I wonder if I should make "editorial" changes to fixup user bugs, > but then there's also bunch of messages which are replies to <y> > because git-send-email had usability problems back in the day... I wouldn't go too far in editorial changes. I made a few when skimming the messages I just sent for spam, and dropped some empty messages, or "unsubscribe me" ones. But it's not worth the human effort to go back and scrub list archives from 10 years ago. Fixing up an extra "<>" is easily done once in your parsing scripts, though, and I'd be surprised if I'm the only one to have made that mistake. > The one which started the thread belonging to > <loom.20100716T103549-783@xxxxxxxxxxxxxx> was really iffy, I think I exercised editorial control over similar "your software is now listed in our archive!" messages in what I sent. But yeah, there's going to be some spam and some cruft in the archive. It's just a fact of life. The solution is good searching and organizing tools to find the signal you're looking for, not to make sure the noise hits zero. > git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4 > > is totally legit, but doesn't seem to show up properly, Heh, yeah, I saw that one (and I think it broke some of my initial scripting, which foolishly assumed nobody had message-ids with spaces in them). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html