[oi-dev] Git as a version control system for new OI projects

[Garrett D'Amore]

On Thu, 2011-06-23 at 01:12 +0400, Alexey Zaytsev wrote:
> On Thu, Jun 23, 2011 at 00:05, Julian Wiesener <jw at vtoc.de> wrote:
> > Hi,
> >
> > as i stated before, i would like to see an proposal than includes some
> > details about what problems a toolswitch will solve. I've absolutely no
> > preference as i used both tools. However, if we do a switch, we should
> > have good reasons for that.
> 
> There is no reason besides "more people want git". Everything that can
> be done with git can be done with hg. And the two dvcs are such a huge
> step from cvs/svn that looking from the 10-years old standpoint, there
> is hardly any difference.
> 
> But, we are looking from the year 2011.
> 1) More people know and use git. And it's a fact that hardly needs any
> proving. The Linux kernel, Glibc, X.org, Gnome and KDE, are all
> maintained in git. Now the two major hg users I see are mozilla and
> python. Not puny, but clearly a different weight category. And I
> wanted to name OpenOffice, but it looks like the developers abandoned
> it to fork LibreOffice, and guess which vcs they chose..

You forgot an important one.  Oracle for Solaris development.  That's
why we are using hg actually -- the decision to use hg was made some
years ago when git was not a viable alternative.

I recognize the situation is different now, but it really does come down
to a religious war.

> 
> 2) Some features are not working as well in hg. Local branches require
> jumping hoops. In git, you are usually branching without a second
> thought.

This is the one argument I have heard.  I guess I'm skeptical that crazy
amounts of local branching are a good idea, but I've never really tried
such a work flow.  I worry about massive amounts of branching leading to
integrations with unintended dependencies, but maybe I'm just being
paranoid.

I tend to use hg combined with zfs clones to give me a really good work
flow with lots of individual workspaces with isolated changes.
Admittedly I'm making underlying use of ZFS to make this work, but it
works for me.

>  The 'git remote' equivalents are rather pale. I've heard that
> hg is easier to use then git, and maybe this was the case in 2005, but
> git usability has gone a long way since then (I've started using git
> in 06), and I fail to see how hg is any easier now. It seems
> noticeably harder for any non-trivial stuff I'm doing in git. It would
> be nice to hear what's so "easy" in hg that's still hard in modern
> git.

I've not used git much, so I can't comment here except to say that hg is
fairly intuitive, especially for people coming from teamware (which many
of our users used to use -- that's what Sun used internally before
converting to hg.)

There's also hg-git, so you know what: you can use git and I don't
care. :-)  And I don't have to. I can continue to use hg. 

> 
> So a big fat +1 to git.
> 
> > Also we should keep in mind, that we still
> > want to use our upstreams, and we should have a simple way to keep our
> > repos in sync with their repos or merge updates.
> 
> Just check how many upstreams are git, and how many are hg. ;)

Nearly all of OI's upstreams are at Oracle, and are in hg.

	- Garrett

> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev