[LLVMdev] git Status

[james woodyatt]

On Aug 18, 2011, at 10:57 AM, David Greene wrote:
> 
> Did the project ever come to a decision about making a transition to
> git?  I'm trying to do some longer-term planning and it would be helpful
> to know what the roadmap is.

Me too.  I've been catching up on the thread from a couple weeks ago, and I didn't see any clear conclusion.  I have some comments about the Mercurial aspect of the discussion.

On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote:
> 
> Comments on that point [Mercurial and local revision numbers] are welcome.

Oh, I really doubt that's true.

I'm a big Mercurial proponent, c.f. ...

  <http://jhw.dreamwidth.org/1868.html>
  <http://jhw.dreamwidth.org/2049.html>

...but even I know when to shut up and just go along to get along.  If folks want LLVM to use a DVCS instead of Subversion, then I will be cheering from the sidelines if LLVM switches to Git.

For my purposes, I'll just use the HgGit extension <http://mercurial.selenic.com/wiki/HgGit> as my view on the Git repository.  I use that routinely with other projects that use Git as their authoritative DVCS repository, and it works reasonably well.  (There are performance improvements coming in both Mercurial and the HgGit extension that should make life even easier for Mercurial users in the not too distant future.)

On Jul 28, 2011, at 3:56 PM, FlyLanguage wrote:

>>> Have you considered mercurial?
>> 
>> Please lets not go there.
>> 
>> I have to use mercurial form time to time in another project and it is
>> really painful. I use hg<->git bridge as often as possible, but it
>> doesn't work as well as the git<->svn one.
> 
> Ahh, the joy of anectodal evidence.
> 
> I'll add one too: I use bot Git and Hg in numerous projects, and they 
> are both stable and fast DVCS's and have great communities.
> 
> Any one of those two blows svn out of the water in so many ways, and 
> either choice will work great (bridged or not.)

+1 to this rebuttal.

I've a sneaking suspicion from reading Chris Lattner's messages about reviewing patches in a queue that Mercurial's MQ facility would come in handy for that.

  <http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html>

The good news is that with recent Mercurial and Dulwich versions installed, the Hg-git extension is really quite reasonable, and it allows you to use MQ among your distributed Mercurial clones, and still push to a remote Git repository when you've finished editing a patch.  I do this all the time.

One point worth noting about the Hg-git extension is that it *really* isn't very good at letting Git users interoperate with a Mercurial repository, mainly because there is metadata captured in the Mercurial format that Git doesn't know how to represent, but it's very nice for Mercurial users who need to interoperate with a Git repository, where a round-trip from Mercurial through Git and back is completely transparent.

Ignore the kvetching about Hg-git from the Git users.  It's really not made for them, and most of them don't know what they're missing by not using Mercurial natively.

Seriously, I would be pleased to see LLVM switch the authoritative repository from Subversion to Git.  I think it's a good idea for two reasons: A) to improve the integrity of the source code history, by distributing it widely, and B) to improve the performance of source code control operations.  (Using a SVN repository is like sucking cold malt extract through coffee stirring straw.  The speed improvement alone, actually, is reason to do it.)  An important secondary reason for switching to Git is for its hugely improved representation of merge operations over how Subversion operates.

People like me, who hate Git and much prefer to use Mercurial, will generally be able to work with a Git repository using Hg-git, and with much less grousing than we do today using the Subversion repository and Hg-Subversion.  Maybe we won't be as happy as if you picked Mercurial over Git, but we're going to be *greatly* outnumbered by the Git users who would scream bloody murder if you picked Mercurial instead.

In closing, just go with Git and tell people who don't like it to use Mercurial and Hg-git.  We're adaptable.

p.s. The Mercurial subrepositories feature is loads better than git submodules and it's built into the tool.  But never mind that.  Just go with Git and don't look back.  Nobody ever got fired for buying from the market leader.


-- 
j h woodyatt <jhw at conjury.org>