Why git instead of mercurial?

[John Wells]

It seems like the hot new thing these days in Ruby-land is to host
your project in git. Cool....I'm very glad distributed vc is finally
getting the attention it deserves.

However, I'm curious...why are so many in the Ruby community flocking
to git instead of mercurial? It seems that Python/C would be a more
appealing choice than Perl/C...and given that they're largely
feature-identical. I'd appreciate any additional insight you might
provide.

Thanks!
John

 

[Matt Todd]

I really don't think the internal implementation has that much
influence over the popularity of the chosen SCMs. I think it has more
to do with the fact that Git is the fastest (but not by much) and has
a greater deal of general use compared to Mercurial. Also, Git is
fairly low level, and I think that a good deal of the Ruby developers
out there want to have this amount of control over their repos.

Plus, honestly, using Git has improved my project work flow, albeit
subtly, by helping me focus on individual topics when changing code,
and providing me ways of organizing my code. Personally I have grown
to prefer the Git way of managing branches compared to Mercurial (hg
making a separate copy on the HD in a new folder, whereas in Git all
branches are managed in the same folder).

Plus, with GitHub.com now, it's hard to say no. Where's the hghub.com?

Matt

 

[Jason Roelofs]

I find it funny that your only point of comparison between git and
Mercurial is the technology with which said tool is implemented. Last
time I checked, the *only* time developers care about how something is
implemented is if it's Windows only (.NET, MFC). If the tool works,
people will use it.

How about an actual comparison of git and Mercurial functionality wise?

Jason

 

[James Tucker]

I find it funny that your only point of comparison between git and
Mercurial is the technology with which said tool is implemented. Last
time I checked, the *only* time developers care about how something is
implemented is if it's Windows only (.NET, MFC). If the tool works,
people will use it.
Java.

How about an actual comparison of git and Mercurial functionality
wise?

Jason

 

[John Wells]

I find it funny that your only point of comparison between git and
Mercurial is the technology with which said tool is implemented. Last
time I checked, the *only* time developers care about how something is
implemented is if it's Windows only (.NET, MFC). If the tool works,
people will use it.

How about an actual comparison of git and Mercurial functionality wise?

Well, I guess that was my point. From what I understand, git and
mercurial are essentially feature-identical. In fact, the developer of
mercurial spent some time working on git, wanted to change something
that Linus disagreed with, and decided to go off and rewrite git.

There are many, many articles out there comparing the two (google git
versus hg), and while there may subtle differences, the similarities
far outweigh these. In fact, one gent took a chapter out of the
mercurial book, replaced all references to the equivalent git
commands, and said everything else stood on its own.

git is used by the Linux kernel devs and others...mercurial is used on
the bigger Sun projects now (OpenJDK, OpenSolaris), by the Mozilla
foundation, by XenSource, and more.

So, after doing all this reading, it seemed to me that the only thing
left was to look at the underlying technology. And God help me, I'd
rather program in Python and C than Perl and C any day. I assume this
is true for a lot of Ruby developers...while Ruby has its roots in
Perl, it's kinda like being a clean cut metrosexual with embarrassing
redneck parents you still humor and honor, but try not to bring to
social gatherings...

To me, mercurial seems a more natural fit for Ruby software projects.

Thanks,
John

 

[M. Edward (Ed) Borasky]

And God help me, I'd
rather program in Python and C than Perl and C any day. I assume this
is true for a lot of Ruby developers...while Ruby has its roots in
Perl, it's kinda like being a clean cut metrosexual with embarrassing
redneck parents you still humor and honor, but try not to bring to
social gatherings...

Well ... I'd much rather program in Perl than Python. Why, you ask?
Because I've been programming in Perl since about 1994 and I've never
written even a single line of Python. I'm sure Python is a perfectly
wonderful language, but the only thing that would "invite" me to learn
it would be to get paid to write it.

 

[Wincent Colaiuta]

However, I'm curious...why are so many in the Ruby community flocking
to git instead of mercurial? It seems that Python/C would be a more
appealing choice than Perl/C...and given that they're largely
feature-identical. I'd appreciate any additional insight you might
provide.

Approximate composition of Git source files, lines of code:

86048 C (81%)
12959 Perl
6714 Shell

Approximate composition of Mercurial source files, lines of code:

36605 Python (94%)
2048 C

So it's not really "Perl/C" vs "Python/C"; it's more like C vs Python
(and as time goes by the proportion of C in Git is only getting
higher).

Cheers,
Wincent

 

[Luis Lavena]

Well ... I'd much rather program in Perl than Python. Why, you ask?
Because I've been programming in Perl since about 1994 and I've never
written even a single line of Python. I'm sure Python is a perfectly
wonderful language, but the only thing that would "invite" me to learn
it would be to get paid to write it.

I develop with Python a few years back, but not for that I'm using
Bazaar right now...

I'm using Bazaar instead of Git mostly because 'it just works' on
Windows and have a truly "official commitment" to support it.

Git, on the other hand, need not just some tweaking but also several
external tools to get it working...

Mercurial is similar to Bazaar (on the Windows support) Git-flavored.

Also the low-level and ugly UI git imposses in the workflow is a no no
for me, For those who like to be in control of everything, the
morphing working tress Git uses (one checkout for every branch you
want to do) I see it as something bad.

Example: I decide to branch the stable branch of one project and fix
some issues related to 'feature-x'

Worked on that branch and fired the spec tasks, which will rake 10
minutes to complete.

With git, I can't checkout another branch unless I do another clone.
With Bazaar, on the other hand, I can branch again, and again, and
again... and start hacking on other things right anyway, even the rake
tests didn't complete yet.

Again with UI, keep track of another head in a repo is a mess... git
track foo -b yyy what!?!? The UI is too complex...

If you want to contribute to a project and get something fixed, the
learning curve of the SCM is so steeped that you make contributors go
away...

Don't forget about "I just reverted long-sha-1-goes-here, since
another-long-sha-1-goes-here-too was broken"...

I think is not a Perl/C vs Python/C issue, but Git is the new cool
toy.

Just my point of view,

 

[Robert Dober]

Although I am a perfect fan and user of Mercurial I believe that this
discussion is at least OT if not futile.
If the Ruby team has chosen GIT they either had
(a) no knowledge of Mercurial and GIT just satisfied their needs
(b) known both and decided to use GIT for some (surely perfectly
reasonable, but not really interesting ) reason
and why should they care about the implementation language?
They might have chosen a different DistVCS if it were written in Ruby maybe

Honestly I do not see any connection to Ruby in this thread.

Cheers
Robert

 

[Luis Lavena]

Although I am a perfect fan and user of Mercurial I believe that this
discussion is at least OT if not futile.
If the Ruby team has chosen GIT they either had
(a) no knowledge of Mercurial and GIT just satisfied their needs
(b) known both and decided to use GIT for some (surely perfectly
reasonable, but not really interesting ) reason
and why should they care about the implementation language?
They might have chosen a different DistVCS if it were written in Ruby maybe

Is not Ruby team that choose Git over Hg over Any-Other-DVCS, but most
of the Ruby developers that works on projects (Web frameworks or
tools) decided for Git instead of anything else.

Honestly I do not see any connection to Ruby in this thread.

There is a connection anyway. The option for a VCS/DVCS make difficult
for users contribute back with patches to fix issues.

I know there are a few porjects that still uses CVS (win32utils).

I can't say the choose for Git is alienating the contribution, but I
can say is performing a sort of discrimination and exclusion for those
users that can't integrate Git properly under their platforms or faces
restrictions regarding the tools that can install under their
environments.

Regards,

 

[Paul Brannan]

If the Ruby team has chosen GIT they either had

Ruby itself is developed using svn.

Honestly I do not see any connection to Ruby in this thread.

A lot of Ruby developers these days are moving to git. I think it's
perfectly valid to ask why rather than to blindly follow along.

I wonder how long it will be before we see git support on rubyforge.

Paul

 

[Alexey Verkhovsky]

I wonder how long it will be before we see git support on rubyforge.

Yeah, DVCS makes perfect sense for loosely organized OSS projects.
Last time I asked Tom Copeland (RubyForge admin) about git support, he
said he was trying to make it happen. There was also some mention of
ample spare time in his response, iirc

We had a conversation along similar line on some internal maillist in
ThoughtWorks. Public opinion there seemed to lean towards Mercurial.
Supposedly, it has more streamlined command-line interface, and is
better documented. Plus there is a decent Windows support. Not that
Git is too hard to learn, but this seemed to be the most meaningful
difference anyone could come up with. Plus Windows support, of course.

 

[James Tucker]

I seem to remember matz talking a lot about diversity. Without being
so arrogant as to speak for him, I will say that in my opinion, I
think this is means people should be able to use what they want to,
and I think that's a good philosophy, for the most part.

Most of the more modern VCS support import and export into svn, so I
wouldn't be at all surprised if ruby is already being developed on
several different VCS. This also might actually be a damn good reason
for staying with svn, as it leaves people with more choices.

Is not Ruby team that choose Git over Hg over Any-Other-DVCS, but most
of the Ruby developers that works on projects (Web frameworks or
tools) decided for Git instead of anything else.

And many of those people are:
a) Hype heads
b) Working on OS X for development and BSD / Linux for production
c) Totally don't care about other platforms, maybe even actively.

The hype, most of the e-famous rails people are moving to git. Gits
userbase starts growing even faster.

There is a connection anyway. The option for a VCS/DVCS make difficult
for users contribute back with patches to fix issues.

Mmm, this is why I'm using (with relative regularity) bazaar, hg, git,
svn and cvs (you know, I think there's another one too, somewhere) :-(

I know there are a few porjects that still uses CVS (win32utils).

I can't say the choose for Git is alienating the contribution, but I
can say is performing a sort of discrimination and exclusion for those
users that can't integrate Git properly under their platforms or faces
restrictions regarding the tools that can install under their
environments.

Give me a shout off-list, I've been using git under msys for quite a
while now, and it's ok. The daemon doesn't work, but we can't have
everything :-(

As far as alienation goes, well, the ability to just grab a .git-ball
is quite useful, and it works really gracefully with a lot of the
manual moving around of files that would traditionally leave a mess in
other SCMs. People get used to their workflows though, preference
reigns supreme under pragmatism.

As far as the *underlying* tech goes, I'm really interested in stuff
like this:
http://eigenclass.org/repos/git/gibak/

I would agree with anyone that said Gits front end is lacking, but
also, I've been using it for quite a long time now, and have never
really used the UI.

Things I have noticed moving from svn to git for my personal work
flows is, massive increase in commit frequency, massive increase in
branch and merge frequency, and the ability to truly work anywhere.
This comes largely from the distributed nature however, and so isn't
really that unique to git. I do have to also say though, git is damned
fast if you keep it gc'd. Also, by comparison to svn, it can save you
a hell of a lot of disk space - there is something to this content
tracking malarky.

One final thing, dcommit <3

 

[Marc Heiler]

And God help me, I'd rather program in Python and C than Perl and C any day. I

assume this is true for a lot of Ruby developers...while Ruby has its roots in
Perl, it's kinda like being a clean cut metrosexual with embarrassing
redneck parents you still humor and honor, but try not to bring to
social gatherings...

If software works ok, it does not matter much in what language it is
written.
Personally I would rather pick python than perl, but if the question is
python or perl, then the real answer is:

Ruby.

;-)

PS: One reason why Linux kernel folks like Linus use Perl is because
they can not write Ruby or Python code. Harsh statement? Maybe. But I
found it true for many old C hackers. Especially for Ruby. Some of them
know and write python code, but I dont know any of these methusalems
that uses Ruby.

 

[Robert Dober]

There is a connection anyway. The option for a VCS/DVCS make difficult
for users contribute back with patches to fix issues.

Hmm maybe bad style of mine to declare the thread OT.
I should rather have expressed the failure to understand OP's concern.
A choice has to be made and such choice will always be unfortunate for
those familiar with the *other* tools.
Or is there something particularly difficult with GIT, than in fact I
would understand OP's concern, which I do not, right now.
Cheers
Robert

 

[Luis Lavena]

I seem to remember matz talking a lot about diversity. Without being
so arrogant as to speak for him, I will say that in my opinion, I
think this is means people should be able to use what they want to,
and I think that's a good philosophy, for the most part.

Most of the more modern VCS support import and export into svn, so I
wouldn't be at all surprised if ruby is already being developed on
several different VCS. This also might actually be a damn good reason
for staying with svn, as it leaves people with more choices.

Git svn push on Windows is broken, mostly because it depends on the
perl bindings that MSYS lacks (since it requires a subversion
build....)

Mmm, this is why I'm using (with relative regularity) bazaar, hg, git,
svn and cvs (you know, I think there's another one too, somewhere) :-(

Me too, but decided to use bzr for personal projects and also keep
track of upstream changes in several others that don't have commit
rights or want to branch and try different things on them.

Give me a shout off-list, I've been using git under msys for quite a
while now, and it's ok. The daemon doesn't work, but we can't have
everything :-(

I really don't have problems getting Git working on Windows, I've it
running since way before msysgit get released. But in any case,
requiring so many stuff to get it working (like depending on MSYS)
make things quite complicated: you can use internal commands of
windows while have MSYS in the path (like find and others).

As far as alienation goes, well, the ability to just grab a .git-ball
is quite useful, and it works really gracefully with a lot of the
manual moving around of files that would traditionally leave a mess in
other SCMs. People get used to their workflows though, preference
reigns supreme under pragmatism.

Exactly, get anyone choose whatever they want, anarchy!

I would agree with anyone that said Gits front end is lacking, but
also, I've been using it for quite a long time now, and have never
really used the UI.

By UI I mean the way you access / interface with the tool, name it
command line arguments, CLI or GUI. In case of Git, the complexity of
the commands you need to build to perform simple task put too much
pain in my fingers ;-)

Things I have noticed moving from svn to git for my personal work
flows is, massive increase in commit frequency, massive increase in
branch and merge frequency, and the ability to truly work anywhere.
This comes largely from the distributed nature however, and so isn't
really that unique to git. I do have to also say though, git is damned
fast if you keep it gc'd. Also, by comparison to svn, it can save you
a hell of a lot of disk space - there is something to this content
tracking malarky.

One final thing, dcommit <3

:-D

 

[James Britt]

It seems like the hot new thing these days in Ruby-land is to host
your project in git.

How did you determine this?

 

[James Britt]

I really don't think the internal implementation has that much
influence over the popularity of the chosen SCMs. I think it has more
to do with the fact that Git is the fastest (but not by much) and has
a greater deal of general use compared to Mercurial. Also, Git is
fairly low level, and I think that a good deal of the Ruby developers
out there want to have this amount of control over their repos.

Interesting. I know a number of Ruby people using darcs or hg, but no
one using git. I'm wondering if it's a Railsville thing, not a Rubyland
thing

 

[James Britt]

... but most
of the Ruby developers that works on projects (Web frameworks or
tools) decided for Git instead of anything else.

Data, please.


I keep reading amazing assertion about how "most Rubyists do this" and
"everyone's doing that", but never anything to suggest these are mere
guesses based on selective experiences in specific corners of the vast
Ruby universe.

 

[Avdi Grimm]

It seems like the hot new thing these days in Ruby-land is to host
your project in git. Cool....I'm very glad distributed vc is finally
getting the attention it deserves.

However, I'm curious...why are so many in the Ruby community flocking
to git instead of mercurial?

For that matter, why not Darcs, which has been around a lot longer,
and is generally much simpler to use than Git? Or Bazaar, which tries
much harder than most DVCSes to handle merging of renames robustly?

I don't really get the popularity of Git. Most of the advocacy I've
seen it has really been advocacy for features that all DVCSes have,
which suggests to me that a lot of people are being introduced to DVCS
via Git. Or maybe it's just the "more is better" mindset:

ls /opt/local/bin/git-* | wc -l
142 commands? It MUST be the best!

Personally I think that if you're Linus, Git is undoubtedly the best
tool for the job; but my own workflows don't really resemble Linus'
much. However, in an Open Source world any DVCS is better than no
DVCS, and I'm glad that Git is popularizing the concept.