Comments on: A really unfriendly and not so fair approach to GIT vs. Mercurial http://blog.experimentalworks.net/2009/02/a-really-unfriendly-and-not-so-fair-approach-to-git-vs-mercurial/ Mon, 12 Jul 2010 13:28:59 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Ismael Juma http://blog.experimentalworks.net/2009/02/a-really-unfriendly-and-not-so-fair-approach-to-git-vs-mercurial/comment-page-1/#comment-88 Ismael Juma Sat, 07 Mar 2009 17:47:53 +0000 http://blog.experimentalworks.net/?p=156#comment-88 Hi, Interesting post. The IDE integration is not fully accurate, however. "They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output." The Mercurial plugin for Eclipse is indeed better, but for a different reason than the one you mention. Ironically, the Mercurial plugin for Eclipse is the one that parses shell output (although it uses styles/templates to make it less fragile) while the Git plugin uses a pure Java library, JGit. JGit is a reimplementation of Git in Java and it's still not complete. As you can imagine, the reimplementation is quite a bit of work, and I believe it's the main reason why MercurialEclipse is so far ahead at the moment. Ismael Hi,

Interesting post. The IDE integration is not fully accurate, however.

“They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output.”

The Mercurial plugin for Eclipse is indeed better, but for a different reason than the one you mention. Ironically, the Mercurial plugin for Eclipse is the one that parses shell output (although it uses styles/templates to make it less fragile) while the Git plugin uses a pure Java library, JGit.

JGit is a reimplementation of Git in Java and it’s still not complete. As you can imagine, the reimplementation is quite a bit of work, and I believe it’s the main reason why MercurialEclipse is so far ahead at the moment.

Ismael

]]> By: fa http://blog.experimentalworks.net/2009/02/a-really-unfriendly-and-not-so-fair-approach-to-git-vs-mercurial/comment-page-1/#comment-67 fa Mon, 23 Feb 2009 08:50:57 +0000 http://blog.experimentalworks.net/?p=156#comment-67 Nice summary, as far as my somewhat more limited knowledge on that field is concerned. Maybe your song of choice should've been 'Talking Heads - Road to Nowhere' though :P PS: unintelligle captcha made me restart completely with that post. Nice summary, as far as my somewhat more limited knowledge on that field is concerned.

Maybe your song of choice should’ve been ‘Talking Heads – Road to Nowhere’ though :P

PS: unintelligle captcha made me restart completely with that post.

]]> By: Karl Fogel http://blog.experimentalworks.net/2009/02/a-really-unfriendly-and-not-so-fair-approach-to-git-vs-mercurial/comment-page-1/#comment-64 Karl Fogel Sun, 22 Feb 2009 22:18:27 +0000 http://blog.experimentalworks.net/?p=156#comment-64 Okay, I admit I enjoyed the post :-) . But since you yourself said it's the "most subjective, most pointless approach to this topic ever", I hope I'm allowed to comment on the bzr bashing: I use bzr daily and have been pretty happy with it. It's much faster now than it used to be (did you have speed problems before?) Disclaimer: I started using it because I work for a company (Canonical) that sponsors Bzr development, so it's part of my job. As I read what you wrote about the staging areas and hunk selection in Git, I thought: I've never wanted that, but if I did, it should be implementable in any version control system, including bzr. It seems like essentially an interface between the vcs and the editor, more than between the vcs and its storage backend? Okay, I admit I enjoyed the post :-) . But since you yourself said it’s the “most subjective, most pointless approach to this topic ever”, I hope I’m allowed to comment on the bzr bashing:

I use bzr daily and have been pretty happy with it. It’s much faster now than it used to be (did you have speed problems before?) Disclaimer: I started using it because I work for a company (Canonical) that sponsors Bzr development, so it’s part of my job.

As I read what you wrote about the staging areas and hunk selection in Git, I thought: I’ve never wanted that, but if I did, it should be implementable in any version control system, including bzr. It seems like essentially an interface between the vcs and the editor, more than between the vcs and its storage backend?

]]>