Why is the Go project hosted in Mercurial instead of Git?

[Steven Degutis]

EOM

[Devon H. O'Dell]

Because ponies.

2012/9/6 Steven Degutis <sdeg...@8thlight.com>:
> EOM

[Jim Whitehead II]

On Thu, Sep 6, 2012 at 9:11 PM, Steven Degutis <sdeg...@8thlight.com> wrote:
> EOM

I think it should be red.

[Steven Degutis]

Any chance it's trivial/feasible to switch it over to git now that Google Code supports it?

-Steven

On Thursday, September 6, 2012 2:38:28 PM UTC-5, Peter Russell wrote:

On Thursday, September 6, 2012 12:11:56 PM UTC-7, Steven Degutis wrote:

EOM

The Go project was released before Google Project Hosting supported Git.

[DisposaBoy]

On Thursday, September 6, 2012 8:43:40 PM UTC+1, Steven Degutis wrote:

Any chance it's trivial/feasible to switch it over to git now that Google Code supports it?

-Steven

Why? What's wrong with hg?

 

[chris dollin]

On 6 September 2012 20:43, Steven Degutis <sdeg...@8thlight.com> wrote:
> Any chance it's trivial/feasible to switch it over to git now that Google
> Code supports it?

What would the point be? Is there a problem?

Chris

--
Chris "Kosh" Dollin

[Patrick Mylund Nielsen]

Why?

The codereview stuff is pretty hg-centric, but also works well. I don't find it nearly as irritating as SVN.

[Devon H. O'Dell]

2012/9/6 Steven Degutis <sdeg...@8thlight.com>:

> Any chance it's trivial/feasible to switch it over to git now that Google
> Code supports it?

I don't see why anybody would want to. codereview and the build
infrastructure is currently tied to mercurial. You're free to develop
locally in a git repo yourself if you'd like, but this seems like a
lot of work for near (or less than, depending on your perspective)
zero benefit.

--dho

[Steven Degutis]

I'll take that as a no. Thanks.

-Steven

[Patrick Mylund Nielsen]

Why are you asking, though? Nobody's saying you don't have a valid concern; we just don't know what it is.

[Steven Degutis]

It just seems like a bunch of small reasons git would be preferred to hg. For one thing, hg is slower than git. Secondly hg is written in python, git in C, so that's one less runtime dependency, and quite a one at that. For instance hg installs to my global python installation and as far as I know there is no easy way to uninstall it without digging into the sources to see what goes where, which is not necessarily true about more traditional projects like git which can be installed anywhere using a prefix. Not to mention, git is much more mainstream and thus many more people have it than hg. Also, it would be much easier to fork go on github which is much more popular than google-code, although I concede that it's probably in Google's favor to use their own hosting service. And finally, hg is just a total ripoff of git anyway, and a poor one at that, but again I'll concede that's just a subjective opinion (although an objectively correct one).

-Steven

[Robbie Straw]

Can't speak for the thread parent, but Mercurial is noticeably slower on my machine (MacBook Pro).

No hard statistics, but using the Git mirror of the Go repository certainly felt faster.
(I'm referring to http://github.com/tav/go)

Aside from that, my only other issue is one of familiarity.

Since that mirror on GitHub has fallen out of date. TP might be interested in https://github.com/schacon/hg-git , it could be used to mirror the repository as a Git repo.

Switching the main repo over to Git does not seem like it would offer much tangible benefit when compared to how much pain it would bring to everyone downstream.

On Thursday, September 6, 2012 2:54:40 PM UTC-5, Patrick Mylund Nielsen wrote:

[Glenn Brown]

I speculate that the root cause is this report, from 2008, when Google chose hg over git because hg already supported http:

http://code.google.com/p/support/wiki/DVCSAnalysis

--Glenn

[Graham Anderson]

On Thursday 06 Sep 2012 15:46:17 Devon H. O'Dell wrote:
> 2012/9/6 Steven Degutis <sdeg...@8thlight.com>:
> > Any chance it's trivial/feasible to switch it over to git now that Google
> > Code supports it?
>
> I don't see why anybody would want to. codereview and the build
> infrastructure is currently tied to mercurial. You're free to develop
> locally in a git repo yourself if you'd like, but this seems like a
> lot of work for near (or less than, depending on your perspective)
> zero benefit.

I would imagine many regular Git users find it frustrating not to have the
cheap local branching model amongst other things.

There's an hg plugin for git, which experimentally also allows push. But then
of course you have to somehow hack together codereview support for it...

https://github.com/cosmin/git-hg

[David Wright]

I remember seeing the hg author's tech talk on google video a couple of years before git had really gotten off the ground. I'm pretty sure that git came hg's way in terms of interface in order to address all the loud and early usability complaints.

I prefer git because of the large user base, now. When mercurial came out I didn't have time to rethink how I was already using svn, so I just skipped it. I imagine that's what lot of people did, given that they'd just fled cvs for svn.

hg is fine. I don't like using python myself, but there's some good software written with it. What I don't understand is why someone undertook bzr when hg is so similar.

David

[DisposaBoy]

On Thursday, September 6, 2012 8:11:56 PM UTC+1, Steven Degutis wrote:

EOM

Out of curiosity... how many of you actually plan to contribute to Go? because if you aren't planning to do so I fail to see this situation affects you at all. 

[Steven Degutis]

I would be a lot more likely to if it were using git, and I don't think I'm the only one who feels that way.

-Steven

[Patrick Mylund Nielsen]

Submitting a CL with hg is easier than doing a pull request on GitHub. For extensive development/multiple branches, sure, Git is easier, but you really don't need it to contribute fixes.

[Andrew Gerrand]

Go's development process is linear - we don't branch and merge.
Whether we use hg or git is kinda irrelevant because we don't use
their distributed features anyway. We could just as well be using svn.
(But I'm glad we're not because it certainly has its own issues.)

We chose Mercurial because at the time it was the best VCS supported
by Google Code, and Google has a policy of hosting its open source
projects on its own infrastructure.

We don't want people to "Fork us on GitHub!" hack away and then send
us pull requests. We want contributors who take the time to
internalize the project's style, goals and philosophies.

The choice of VCS is a very small concern in the grand scheme of
things. It seems to me that anyone unwilling to use a different VCS
may also be unwilling to make the many other compromises required to
work effectively on a large open source project.

Incidentally, I just noticed we now have more than 300 names in the
CONTRIBUTORS file. Amazing! Thanks everyone!

Andrew

[T.J. Yang]

Hi Steven

FYI, git  still have a few bugs(issue 28389&28508) that stop me from using git seriously on code.google.com.

tj

[MaxTheMouse]

>
> hg is fine. I don't like using python myself, but there's some good software written with it. What I don't understand is why someone undertook bzr when hg is so similar.
>
> David
>

As far as I know, bzr is slightly older than hg and started as baz.
The trio of bzr, hg and git all came out at about the same time
though. It is no surprise that all three borrowed heavily from each
other and so there are many similarities. FWIW I actually started out
with bzr for small projects than moved to hg for queues.

cheers,
Adam

[Martin Bruse]

From Wikipedia:
----
First generation open-source DVCS systems include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others. Among them, Mercurial and Git were created as potential replacements for BitKeeper when it was pulled from free use by the Linux kernel project by its publisher. Bazaar followed not long after.
----
What they don't mention (there) is that Bazaar is a fork off Arch, and that Monotone was the inspiration for both Git and Mercurial.

The sad thing is how the Monotone team spent a couple of months optimizing the hell out of mtn after Torvalds dissed their performance, and when they were done (mtn is now about the same speed as its competition) he had already begun (and decided for) git instead.

I see it as another Betamax/VHS story :)