The fast-export --anonymize item is interesting. I've used a few tools professionally that I've been unable to feasibly report some bugs for, because any time I produce a log file (or whatever) it's filled with file names or email addresses or function names or code snippest or paths or whatever. Or if it's an example file, it contains copyrighted information that one can't just go giving away to 3rd parties.<p>Had there been some kind of anonymization option, on the other hand, there'd have been no problem. As it is, I just have to produce some hand-wavey bug report, that's as accurate as I can make it - that then presumably gets put on the shelf with all the other random unclassifiable oddities that nobody has time to look at properly. Because they're too busy dealing with the bugs that actually came with data.<p>(Of course, sometimes the data itself <i>is</i> the problem, and then this wouldn't help. Then other times, the system in question has faulty RAM. This wouldn't help with that either.)
I love the slightly anthropomorphized language used in this.<p>> "git archive" learned to filter what gets archived with a pathspec.<p>> "git mergetool" understands "--tool bc" now<p>> The pretty-format specifier "%d" [...] gained a cousin "%D"
And once again there is a need for a friendly reminder:
If you release a bit of software and wish the audience to pay more attention than they would to any average maintenance releases:<p>Put something in the title of the release announcement to explain what makes this one special.<p>Try to do it in a way that makes sense to someone who rarely ever even uses your software.