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>