

Git v2.2.0 released - pentium10
http://lkml.iu.edu/hypermail/linux/kernel/1411.3/02881.html

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

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.

(Of course, sometimes the data itself _is_ 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.)

------
andrey-p
I love the slightly anthropomorphized language used in this.

> "git archive" learned to filter what gets archived with a pathspec.

> "git mergetool" understands "\--tool bc" now

> The pretty-format specifier "%d" [...] gained a cousin "%D"

~~~
mostafah
Yes, that’s awesome. They’ve always been doing that. I love that too.

------
Mithaldu
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:

Put something in the title of the release announcement to explain what makes
this one special.

Try to do it in a way that makes sense to someone who rarely ever even uses
your software.

~~~
PeterWhittaker
That seems a trifle petty: Just skimming through the list of updates and I'm
already impressed by the content, and I've not even gotten to the fixes yet.

There is no "one-liner" that will capture this, save perhaps something near-
linkbaity like "git 2.2.0 - almost a hundred contributors, 20 brand new, with
dozens of updates and dozes of fixes! Whew!"

Having said that, the announcement of a point release like this isn't the
place to appeal to those who are not git users: This notice is aimed squarely
at those who are git users and need to know whether or not they should
upgrade.

Marketing communication is all about understanding your market, its segments,
and the messaging each segment needs. This announcement isn't for newbies or
notbies.

If there is a grain of truth in your comment, then it is that a separate
announcement is needed, a more general press release, aimed perhaps at the
wider community, to whit:

Team responsible for world's most popular distributed revisioning system
announces update

Git, the world's most popular distributed revisioning system, has been
updated, according to announcements released this morning to the development
community.

The new release features contributions from over 70 contributors, 20 of whom
mark their git release debut. This version, dubbed 2.2.0, contains
approximately two dozen fixes to the 2.1 release as well as several dozen
backwards-compatible new features.

The development team is thrilled and proud of their work and eagerly awaits
community feedback.

<Insert standard description of git here>

<Insert list of major git projects here>

<Insert upgrade roadmaps for GitHub and other git-as-a-service providers>

<Insert standard description of revision control here>

<Insert standard "considering switching to git? look here"?>

<Insert standard "new to git? look here">

(All of the above CC-BY-SA, feel free to use as desired.)

~~~
randallsquared
> something near-linkbaity like "git 2.2.0 - almost a hundred contributors, 20
> brand new, with dozens of updates and dozes of fixes! Whew!"

Titles like that are linkbait when the document linked is not actually worth
the hype of the title. Actually descriptive titles like your example are great
titles in my opinion, except possibly the last bit with exclamations.

------
Already__Taken
And still the windows build remains 1.9.4. Am I missing something?

~~~
cesarb
The Windows build is made by the msysGit team
([https://msysgit.github.io/](https://msysgit.github.io/)), which is a
separate team with a chronic lack of manpower.

The Git situation on Windows is somewhat like openssh versus portable openssh,
or libressl versus portable libressl: it's originally developed for one
system, and a separate project ports it to another system. It's a bit harder
for Git on Windows, since Git was written expecting a POSIX system (parts of
Git are written in shell or Perl, for instance), and Windows is different
enough to give it trouble.

If you want Git on Windows to be more up-to-date, give them a help; I'm sure
they'll appreciate it.

------
javajosh
And yet on OSX Yosemite:

    
    
       $ git --version
       git version 1.9.3 (Apple Git-50)

~~~
gutnor
Trivial to get an newer version though, for example through homebrew.

Here is what I have, currently (haven't updated in a while)

    
    
        $ git --version
        git version 2.0.3
    

For windows, it is another matter, seems officially stuck at 1.9.4 since
forever ([http://git-scm.com/download/win](http://git-scm.com/download/win))

