I agree with most of the points you make and I’d love for Emacs to adopt git, but judging from the last discussion on the topic a few months ago (http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html), I don’t think that’s going to happen any time soon.

Btw, Richard said then he wanted to give bzr’s maintainer a reasonable amount of time to fix some bugs (or so I recall). If this hasn’t happened - there’s one more argument in favour of using git. Relying on a poorly maintained project is generally worse than relying on a unpopular project.  

--  
Cheers,
Bozhidar


On Thursday, January 2, 2014 at 11:53 AM, Eric S. Raymond wrote:

> I am posting this because I think it is my duty as a topic expert in
> version-control systems and the surrounding tools to do so, not because
> I have any desire to be in the argument that is certain to ensue.
>  
> The bzr version control system is dying; by most measures it is
> already moribund. The dev list has flatlined, most of Canonical's
> in-house projects have abandoned bzr for git, and one of its senior
> developers has written a remarkably candid assessment of why bzr
> failed:
>  
> http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html
>  
> I urge all Emacs developers to read this, then sleep on it, then read
> it again - not least because I think Emacs development has fallen into
> some of the same traps the author decribes. But *that* is a discussion for
> another day; the conversation we need to have now is about escaping
> the gravitational pull of bzr's failure.
>  
> In theory, that failure need not affect us at all providing the bzr
> codebase is sufficently mature to continue in use as a production
> tool. I judge that, in fact, it *is* sufficiently mature.
>  
> In practice, I judge that sticking with bzr would have social and
> signaling effects damaging to Emacs's prospects. Sticking to a  
> moribund version-control system will compound and exacerbate the  
> project's difficulty in attracting new talent.
>  
> The uncomfortable truth is that many younger hackers already think
> Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
> stuck in the last century. If we're going to fight off that image, we
> cannot afford to make or adhere to choices that further cast the
> project as crusty, insular, and backward-looking.
>  
> As of right about now, continuing with bzr is such a choice. We'll
> lose potential recruits, not merely because bzr has a learning cost
> but because crusty, insular, etc. The opportunity cost of not getting
> out will only rise with time.
>  
> git won the mindshare war. I regret this - I would have preferred
> Mercurial, but it too is not looking real healthy these days. I have
> made my peace with git's victory and switched. I urge the Emacs
> project to do likewise.
>  
> I can be technical lead on the migration - as the author of
> reposurgeon I have the skills and experience for that (I recently
> moved GNU troff from CVS to git). But the project leadership needs
> to make the go decision first.
> --  
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>  
> No one who's seen it in action can say the phrase "government help" without
> either laughing or crying.
>  
>