>> I think the problems it would solve for us are (1) emailing huge >> patches around sucks (it sucks unnecessarily because of the >> mailing-list size limit, but even if someone fixes that, it still >> sucks), (2) no need for a CVS-to-GIT conversion that may incur dirty >> reads; (3) retention of history and authorship when merging patches >> into core. It's possible that it might change our workflow in other >> ways too, but even if we got only those three things I think that > > O.k. now the second part :) > > Does bzr, mecurial or monotone offer the same or better solution? Bzr in > particular is in very wide use and I run into mecurial all the time.
I'm sure we could make any of them work, but the fact that git.postgresql.org already exists and hg.postgresl.org, bzr.postgresql.org, etc. do not may be suggestive of something - that it would be less work to finish the job, if nothing else. I also think there is some evidence to suggest that git is evolving very rapidly. You could view that as a negative thing, but I don't mean they're fixing bugs: I mean they're adding features. That suggests both that (1) if git doesn't have feature X that you want now, it's likely to have it in the not-too-distant future and (2) a lot of other people like git well enough that they're both using it themselves and contributing changes back to the community, which is an endorsement of the product generally. git definitely has some downsides. The initial repository clone is kind of expensive, and there's a learning curve (though it's much flatter than it was in the past). So I don't think it's the greatest thing ever. But I think it's pretty good, and based on the spike in a/... and b/... paths in recent patches, I'm not the only one. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers