Git vs. Mercurial: Please Relax(importantshock.wordpress.com)
importantshock.wordpress.com
Git vs. Mercurial: Please Relax
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
8 comments
...What if there was a wiki that people could use to participate in the documentation, and then that documentation would become the man page with the next release? Everyone wins?
I like and use both man pages and wikis, but I'm not sure how I would even begin to participate in helping with documentation for something like a man page if I wanted to. The actual creation of the man page itself, as I understand it, is a single-user task. If you want community involvement to get source material, you're going to have to have an accessible participatory mechanism; a wiki, essentially, in whatever form that may take. But it should be easy, no?
I suppose there's also the counter argument that "people who need wikis to participate in something like git documentation are probably not the people we want writing git documentation."
I like and use both man pages and wikis, but I'm not sure how I would even begin to participate in helping with documentation for something like a man page if I wanted to. The actual creation of the man page itself, as I understand it, is a single-user task. If you want community involvement to get source material, you're going to have to have an accessible participatory mechanism; a wiki, essentially, in whatever form that may take. But it should be easy, no?
I suppose there's also the counter argument that "people who need wikis to participate in something like git documentation are probably not the people we want writing git documentation."
Well put. I'm appalled that people keep promulgating this FUD about git documentation. Git's User Manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual....) is the first hit on Google for "git manual". From my reading, it's roughly equivalent to the much-lauded Mercurial book.
The author then writes: "I installed git through MacPorts, only the main git tool comes with a man page, leaving me to consult the Web to find out exactly how to format revision specifiers." He did not seem to realize that the git-core port has a nifty variant "+doc", which installs full documentation, including the aforementioned manual.
The author then writes: "I installed git through MacPorts, only the main git tool comes with a man page, leaving me to consult the Web to find out exactly how to format revision specifiers." He did not seem to realize that the git-core port has a nifty variant "+doc", which installs full documentation, including the aforementioned manual.
Like the constitution.. it is written on parchment! Parchment! How terrible. You can't search it or handle it with your bare hands.
That being said, it is easier to update a wiki than to get a man page updated. This may foster better or more documentation, but ultimately the format does not dictate the utility.
That being said, it is easier to update a wiki than to get a man page updated. This may foster better or more documentation, but ultimately the format does not dictate the utility.
All this hg vs git, but no one remembers monotone (which had some influence on git's development)
www.monotone.ca
Its a single file binary
Its supported on windows, linux, solaris and mac
has an interface for both scripts and users
Great documentation (and an easy to follow tutorial)
Interface is Stable
Single file to store the repo. I enjoy this b/c it makes backups extremely easy.
Negatives are:
It may not be as fast as Git, but the difference is barely noticeable.
Pulling an initial repo from the master is slow when there are tens of thousands of commits in the tree. After the initial pull, sync's between repos are quick.
Diffs in MS Windows takes substantially longer than in linux.
Monotone may not be a perfect choice for the linux kernel, but its a great DVS that's easy to use, stable and lets linux/mac/windows guys work together.
www.monotone.ca
Its a single file binary
Its supported on windows, linux, solaris and mac
has an interface for both scripts and users
Great documentation (and an easy to follow tutorial)
Interface is Stable
Single file to store the repo. I enjoy this b/c it makes backups extremely easy.
Negatives are:
It may not be as fast as Git, but the difference is barely noticeable.
Pulling an initial repo from the master is slow when there are tens of thousands of commits in the tree. After the initial pull, sync's between repos are quick.
Diffs in MS Windows takes substantially longer than in linux.
Monotone may not be a perfect choice for the linux kernel, but its a great DVS that's easy to use, stable and lets linux/mac/windows guys work together.
And if you enable inode caching, it's substantially faster. I wonder why this isn't a default -- it seems like it is for hg and git, but people miss the option in mtn and write it off as being slow.
Summary: neither is ready yet. Wait for one to get good enough to make the other unnecessary.
My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
Ok, that question wasn't rhetorical, I'm curious.
My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
Ok, that question wasn't rhetorical, I'm curious.
I'd say they're both ready, and I've used them both for over a year now with no problems.
My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
I prefer hg for just this reason. But unfortunately, it looks like git is going to win. Why? http://github.com. Fortunately, they're both pretty good, and so living with git isn't the end of the world.
My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
I prefer hg for just this reason. But unfortunately, it looks like git is going to win. Why? http://github.com. Fortunately, they're both pretty good, and so living with git isn't the end of the world.
I agree that it looks like git is going to win, but for entirely different reasons:
1) The person who wrote it is famous. It wouldn't have been taken seriously had (almost) anyone else written something comparable.
2) Network effects apply strongly here. You can't just use something else if you want to collaborate with people who use it.
I'm not very happy about having to use git, but the pain numbs after a while. And, to be fair, it does have some cool features, although little-to-nothing inherent to git or its implementation.
1) The person who wrote it is famous. It wouldn't have been taken seriously had (almost) anyone else written something comparable.
2) Network effects apply strongly here. You can't just use something else if you want to collaborate with people who use it.
I'm not very happy about having to use git, but the pain numbs after a while. And, to be fair, it does have some cool features, although little-to-nothing inherent to git or its implementation.
I use git, so I'll explain a few things I like about it.
1. I can commit things locally before committing them to the main repository. This allows me to commit something in a manner that separates it from all future changes, but test it for a few more days in future development before I actually push it to the main repository.
2. I can correct past commits. This means I don't have to clutter up the history with "fix typo"; I can just amend the previous commit. Obviously this isn't useful for stuff far back, but if I commit something and 2 minutes later someone points out a typo, I can fix it. A messy history makes development and bugfinding harder; git helps avoid it.
3. Git diff is formatted a bit more nicely than svn diff, IMO.
1. I can commit things locally before committing them to the main repository. This allows me to commit something in a manner that separates it from all future changes, but test it for a few more days in future development before I actually push it to the main repository.
2. I can correct past commits. This means I don't have to clutter up the history with "fix typo"; I can just amend the previous commit. Obviously this isn't useful for stuff far back, but if I commit something and 2 minutes later someone points out a typo, I can fix it. A messy history makes development and bugfinding harder; git helps avoid it.
3. Git diff is formatted a bit more nicely than svn diff, IMO.
I hate to point out the painfully obvious, but the discussion in this article isn't about why one should use a DVCS, but about the respective pros and cons of Git and Mercurial.
Your comment is a little like saying "man, a visual text editor sure beats using ex on a teletype!" in the middle of a vi/emacs war.
Your comment is a little like saying "man, a visual text editor sure beats using ex on a teletype!" in the middle of a vi/emacs war.
But I'm not responding to the article; I am responding to the parent post, who asked the following question:
"Really, why so many more commands for essentially the same work cycle?"
"Really, why so many more commands for essentially the same work cycle?"
I prefer git because my work uses SVN, and nobody needs to know I'm using git-svn.
Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.
Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.
As such, the git project has consciously made no effort to make the migration to git easy: the revert command in Subversion resets your current working copy to the last commit, but in git undoes a supplied patch and commits the changes needed to remove that patch. (The equivalent command for svn revert in git is git reset --hard HEAD^.)
Yes. You can't just make shit up and expect the computer to understand what you mean. Last time I checked, git came with extensive documentation. Try reading it :P
Anyway, I think hg takes the right approach to design -- a library that some shell scripts call into. Git takes a non-ideal approach -- monolithic scripts all written in different languages that sometimes share nothing. (Or more often, call each other to "abstract away" some details.)
But despite this, git is much nicer to use. It's more flexible, more consistent, and has a lot of really nice sugar. But I guess if you think svn is the only way revision control can work, you won't like it. Your loss. <link to "Beating the Averages">.
Yes. You can't just make shit up and expect the computer to understand what you mean. Last time I checked, git came with extensive documentation. Try reading it :P
Anyway, I think hg takes the right approach to design -- a library that some shell scripts call into. Git takes a non-ideal approach -- monolithic scripts all written in different languages that sometimes share nothing. (Or more often, call each other to "abstract away" some details.)
But despite this, git is much nicer to use. It's more flexible, more consistent, and has a lot of really nice sugar. But I guess if you think svn is the only way revision control can work, you won't like it. Your loss. <link to "Beating the Averages">.
mercurial is one binary you say?
well hg is basically just this:
from mercurial import demandimport; demandimport.enable()
import sys import mercurial.util import mercurial.dispatch
for fp in (sys.stdin, sys.stdout, sys.stderr): mercurial.util.set_binary(fp)
mercurial.dispatch.run()
....
that is a front end for this: ancestor.py demandimport.py hook.py mail.py simplemerge.py util.py archival.py dirstate.py httprangereader.py manifest.py sshrepo.py util_win32.py bundlerepo.py dispatch.py httprepo.py mdiff.py sshserver.py verify.py byterange.py extensions.py i18n.py merge.py statichttprepo.py __version__.py changegroup.py fancyopts.py ignore.py node.py streamclone.py version.py changelog.py filelog.py __init__.py osutil.py strutil.py cmdutil.py filemerge.py keepalive.py patch.py templatefilters.py commands.py hbisect.py localrepo.py repair.py templater.py context.py help.py lock.py repo.py transaction.py copies.py hg.py lsprof.py revlog.py ui.py
so what are you talking about?
from mercurial import demandimport; demandimport.enable()
import sys import mercurial.util import mercurial.dispatch
for fp in (sys.stdin, sys.stdout, sys.stderr): mercurial.util.set_binary(fp)
mercurial.dispatch.run()
....
that is a front end for this: ancestor.py demandimport.py hook.py mail.py simplemerge.py util.py archival.py dirstate.py httprangereader.py manifest.py sshrepo.py util_win32.py bundlerepo.py dispatch.py httprepo.py mdiff.py sshserver.py verify.py byterange.py extensions.py i18n.py merge.py statichttprepo.py __version__.py changegroup.py fancyopts.py ignore.py node.py streamclone.py version.py changelog.py filelog.py __init__.py osutil.py strutil.py cmdutil.py filemerge.py keepalive.py patch.py templatefilters.py commands.py hbisect.py localrepo.py repair.py templater.py context.py help.py lock.py repo.py transaction.py copies.py hg.py lsprof.py revlog.py ui.py
so what are you talking about?
Apples to oranges. That's comparable to listing every source file in git.
How many of those do you ever execute directly? (How many are even in your shell execution path?) All of the interaction with it is namespaced behind the hg executable, including extensions.
How many of those do you ever execute directly? (How many are even in your shell execution path?) All of the interaction with it is namespaced behind the hg executable, including extensions.
what's the difference?
hg status -someflag | xargs do-something
git-status -someflag | xargs do-something
as far as usage is concerned -- is hg really less tool like? you're right, it is partly semantics. however the article over-simplifies things to the point of being misleading.
hg status -someflag | xargs do-something
git-status -someflag | xargs do-something
as far as usage is concerned -- is hg really less tool like? you're right, it is partly semantics. however the article over-simplifies things to the point of being misleading.
One semantic/aesthetic difference is that git floods tab completion with all the git- items, which is needlessly annoying. Namespacing the entire public interface behind one executable feels cleaner.
I suspect the underlying reason people complain about this is that it's a particularly visible instance of hg having a vastly cleaner public interface than git. Of course, one person's "feeling cleaner" is another person's "easier to write scripts/extensions for that won't break every time the public interface to the relevant exposed internals change in the slightest way". There seems to be much less effort to encapsulate the git interface for consistent external usage.*
Some people will prefer git for just this reason, though: You can easily get at the internals, if necessary. Like most of these "holy wars", it's a trade-off, and different people have different values. Make an informed decision. (Git's design values seem to resemble C's, while hg more closely fits Python's. I strongly prefer the latter.)
* This is unsurprising, though: Linus has spoken rather condescendingly of monotone's "nice object-oriented libraries". (http://lwn.net/Articles/249460/) (He also complained that it was slow, though he caught it at a particularly bad time -- one of the lead developers had just gone on sabbatical (and was preparing to move across the country), and the issues causing the sluggishness were fixed shortly after.)
I suspect the underlying reason people complain about this is that it's a particularly visible instance of hg having a vastly cleaner public interface than git. Of course, one person's "feeling cleaner" is another person's "easier to write scripts/extensions for that won't break every time the public interface to the relevant exposed internals change in the slightest way". There seems to be much less effort to encapsulate the git interface for consistent external usage.*
Some people will prefer git for just this reason, though: You can easily get at the internals, if necessary. Like most of these "holy wars", it's a trade-off, and different people have different values. Make an informed decision. (Git's design values seem to resemble C's, while hg more closely fits Python's. I strongly prefer the latter.)
* This is unsurprising, though: Linus has spoken rather condescendingly of monotone's "nice object-oriented libraries". (http://lwn.net/Articles/249460/) (He also complained that it was slow, though he caught it at a particularly bad time -- one of the lead developers had just gone on sabbatical (and was preparing to move across the country), and the issues causing the sluggishness were fixed shortly after.)
git is pretty good at dealing with lots of local branches. it has git-stash which supports that even further (stash it now, come back to it later). it has a staging area which allows you to slice and dice your commits. it seems to be better and allowing you to rewrite the commit history.
i don't like git-repack, git-gc. i prefer the hg revlog approach.
hg can package all of its state from a given commit into what they call bundles. git only has git-format. can git-format be as self-describing as a bundle?
you can't delete named branches from mercurial. i say, so what. we have an inactive branch. we merge uninteresting branches into there. hg branches -a then shows you the unmerged (active) branches.
they're both good. it mostly depends on the way you and your team work.
i don't like git-repack, git-gc. i prefer the hg revlog approach.
hg can package all of its state from a given commit into what they call bundles. git only has git-format. can git-format be as self-describing as a bundle?
you can't delete named branches from mercurial. i say, so what. we have an inactive branch. we merge uninteresting branches into there. hg branches -a then shows you the unmerged (active) branches.
they're both good. it mostly depends on the way you and your team work.
Agreed. I prefer hg overall, but I know it's more due to style than a clear technical advantage one way or the other.
Is it possible to set branches -a to be the default in your hgrc, by the way? (I was going to check on that this weekend.)
Is it possible to set branches -a to be the default in your hgrc, by the way? (I was going to check on that this weekend.)
i don't think so no. you may have to go with a wrapper script or an alias.
do you know if it's possible to do bundles in git?
do you know if it's possible to do bundles in git?
Haven't tried, sorry.
It looks like you can add
It looks like you can add
[defaults]
branches = -a
Instead of arguing for one over the other, how about volunteering your time and skills toward improving your favorite's weak areas? They're both quite good, but there's always room for improvement. Give something back!
For example, if I have time this weekend, I'm going to work on adding support for hg's record extension to its (already quite good, IMHO) Emacs interface.
For example, if I have time this weekend, I'm going to work on adding support for hg's record extension to its (already quite good, IMHO) Emacs interface.
Feels like a bike shed to me. The other %99 of the world is still using cvs or subversion or something else, waiting to see what proves stable over a number of years. Companies are going to thrive or fail depending on the products they create, not the version control system they use.
I could be doing a lot more creating at my company if I wasn't shackled to our out-of-date version control system.
This is actually a serious issue which is finally getting traction to fix at the management level.
This is actually a serious issue which is finally getting traction to fix at the management level.
> This is actually a serious issue which is finally getting traction to fix at the management level.
I'm guessing that 'version control' is just one symptom of other underlying problems. I just don't buy that you're not creating a good product because of version control.
I'm guessing that 'version control' is just one symptom of other underlying problems. I just don't buy that you're not creating a good product because of version control.
Oh, there are absolutely other problems. I'm not trying to pin all the problems on CVS. It's just a major pain point which can actually be addressed with a technological, rather than a cultural, solution.
The root problem is probably extreme conservatism coupled with an unwillingness or inability to sensibly delegate responsibility, which adds up to systemic paralysis when it comes to actually getting things done. It is not a Hacker-friendly place. I'm fortunate enough to be in a small team which manages to bypass a lot of the mess, but I'm still not sure how long I actually want to stay here.
The root problem is probably extreme conservatism coupled with an unwillingness or inability to sensibly delegate responsibility, which adds up to systemic paralysis when it comes to actually getting things done. It is not a Hacker-friendly place. I'm fortunate enough to be in a small team which manages to bypass a lot of the mess, but I'm still not sure how long I actually want to stay here.
What version control system are you using?
CVS. It just doesn't fit well with our workflow.
Despite that glaring flaw, the rest of hg is excellent. It functions almost identically to Subversion in the commands that it shares, and the new concepts - branching, merging, etc.
why exactly does the author refer to branching/merging as new concepts?
why exactly does the author refer to branching/merging as new concepts?
This brings us to another of git’s faults: its documentation is terrible. Man pages are no longer a sufficient replacement for a good, well-updated wiki or reference work;
Huh? This is the kind of thing that IT pedants say when they don't have any better arguments. There's absolutely nothing wrong with a good man page (or, to be sure, any documentation format at all). /usr/bin/man, in 2008, is still my first choice for looking up the interface to system calls, C APIs and command line utilities like git.
Now, could some of git's man pages use some work? Sure. But make that the criticism. Smacking about the format is just dumb.