Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
This forum is in permanent archive mode. Our new active community can be found here.
DVCS and You! (and ice cream)
Note: This is not in the flame wars section.
Arguments for and against Github (using git) and Bitbucket (using mercurial).
I honestly prefer mercurial to git, because while I like being hard core as the next person, I find the interface for mercurial to be a lot more user friendly. Ultimately my choice of mercurial over git is similar to my choice of Python over say C or Java.
I've not used either github or bitbucket. I assume bitbucket would be my choice simply because I prefer mercurial. Perhaps people can shed light on those services and/or alternatives beyond "I run git/hg repos on my personal server".
EDIT (2011/06/26): Changing topic from "Github v. Bitbucket" to "DVCS and you!"
Arguments for and against Github (using git) and Bitbucket (using mercurial).
I honestly prefer mercurial to git, because while I like being hard core as the next person, I find the interface for mercurial to be a lot more user friendly. Ultimately my choice of mercurial over git is similar to my choice of Python over say C or Java.
I've not used either github or bitbucket. I assume bitbucket would be my choice simply because I prefer mercurial. Perhaps people can shed light on those services and/or alternatives beyond "I run git/hg repos on my personal server".
EDIT (2011/06/26): Changing topic from "Github v. Bitbucket" to "DVCS and you!"
Comments
No matter which one you prefer, I think it's in a programmers interest to just give up and use Git even if you prefer Mercurial. Github is the most popular by far. Git is good enough for the Linux Kernel, so it's good enough for you. Also, while its user friendliness is lacking, Git is technologically superior under the hood. I'm simultaneously glad and surprised that Git has sort of "won" this battle of the VCS. It's like if Vim was actually the most popular text editor.
Also, glad that Mercurial exists because there always needs to be choice, alternatives, competition, etc.
Also, I was using Git over a year before it became popular at all, so I'm kind of an expert-ish now. If you are having trouble understanding Git, there is an excellent and short PDF that explains everything in an amazing way. http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
In mercurial, you can pull from a distribution and then it is a local repo. You can modify that as a local fork as much as you want using SVN-like syntax (i.e. not using "pull" to update your local repo from a remote one). You can continue to pull from a remote repo into your own and perform merges as you desire (keeping your local branch still separate from some remote branch). I'm not sure if I understand. Do you mean something else by a local branch? So the user friendliness can easily be overcome by some front-ends. Does anyone know of any? I'm primarily a Linux user (Ubuntu specifically), but if you have suggestions for other OSes or dev environments, might as well cough those up
EDIT: I think my response to this was nitpicking. Colored white in case you're curious:
I'm not sure I like this statement. It is true that it is good enough for a great many, many projects (not just linux kernel). The phrasing seems to be saying that "mercurial is not good enough for linux kernel", which I'm not sure can be said. I understand Linus developed Git, so I'd be hard pressed to say there wasn't a bias in the choice of the Linux community utilizing Git.
That's one reason it won't work for Linux. There are so many developers all around the world, imagine if they all had all of each other's branches. Instead with Git people email pull requests or patches directly to the lieutenant or Linus himself. Then those patches can be explicitly pulled without pulling anything else.
User friendliness can sort of be overcome by a front end, but I highly recommend against using any front end whatsoever. Everyone should use the command line. It's ok to use a front end to visualize your logs or your history, but you shouldn't be using one to actually perform any operations on your code. I'm not saying this because I'm an old man who thinks punk kids should walk fifteen miles in the snow instead of taking the bus. I'm saying it because version control is an essential part of software development. It's also incredibly complex no matter what system you use, especially so with Git.
Any GUI will necessarily hide a lot of that complexity. If you never do anything fancy, you just commit in a straight line and make a few branches, you will never have a problem. But then why are you using Git in the first place? If you actually try to use Git with a GUI you will eventually shoot yourself in the foot. Then because you've only ever used a GUI you won't know that your accidental hard reset can be trivially fixed by checking the ref log and doing another reset. Git is a real Hole Hawg. Sticking inside a plastic case to make it consumer friendly will just get people killed.
The primary reason that Git is technologically superior is that it has two guarantees. Guarantee number one is that the code you put in will be the code you get out. You would be surprised, but very few other VCS's guarantee this. Git creates an SHA hash of every single blob. If anything at all is even one bit off, you will know. Every single bit goes into Git unmodofied and comes out exactly the way you put it in. Likewise, everything you do in Git is safe and reversible. The only way you can lose something in Git is to remove absolutely all references to it and run the garbage collector. It's really really hard to do something that is not undoable. Your code is ultra safe.
These concerns might not seem important for a small project, but they are essential for say, the Linux Kernel. Go read some stories about people accidentally losing data by putting a wrong command in Mercurial. Not possible with Git. It might be complex and non-obvious as to how to undo something or to get your code the way you want, but it is always possible. The more you understand about how Git works under the hood and what exactly each command does under the hood, the more obvious it will be to you the shortest path to getting your code in the shape you desire. Read the pdf I linked.
I have never actually used a GUI or other front-end for any kind of VCS (unless you count the apt repo as a VCS), so I don't know how much is hidden or not. I'll try to help friends on Windows who are using TortoiseXXX, but I have no idea how to do anything. I just assumed it was that I simply had to learn how to use the front-end rather than those features were absent.
I did not know HG lacked hashing features. I got the feeling it doesn't store the hashes in the repo, although I am pretty sure anytime a transfer occurs, hashes are used (rsync style). If that is correct, bitrot could occur undetected if the repo is corrupted outside the HG environment, which is absolutely possible. I also thought HG kept everything in diffs, even deleted files, as I assumed it was just like Subversion but with push/pull commands.
I will read the PDF as I've never been able to get my head around git previously.
Related to DropBox, apparently DropBox hash codes uploads and someone had found out how to fake a file upload to any hash code. This basically allowed a user to make DropBox think the user uploaded a file the user didn't have. This could be used birthday attack style to find files in random people's boxes (not mentioned, but it's obviously a possibility; couldn't really target anybody though), or as the article notes, make piracy a lot easier. I believe this has since been fixed somehow.
The short of it is that hg vs. git doesn't matter for most things. The win is that developers are starting to use DVCSes.
One other thing to keep in mind is that if you're working on Windows, Mercurial is probably the better choice as Git's Windows support tends to be a bit flaky (though it is getting better, but it's not quite at feature parity with the Unix versions yet). That's one of the reasons why Mozilla decided to use Mercurial and not Git for Firefox's version control.
Personally, I like both, but I prefer Mercurial by a smidge due to its better Windows support and greater ease of use. However, I'd have no problem with using either one of them if it was the choice for any particular project I was working on.
http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1
These guys were aware that 2.6.38 had worse battery life on many laptops than 2.6.37. They knew that one of the many commits between those two tags was the cause of the problem, but which one? Enter git-bisect. You tell it a commit that you know doesn't have a problem, and it will roll forward through history one commit at a time. At each commit it stops and you can run tests manually and/or automatically. You can then either manually mark that commit as good or bad or have the result of the automatic tests do that. This will allow you to easily find the precise commit causing the hidden issue.
These guys at Phoronix used the Phoronix test suite as the automatic tests and were trivially able to find the precise commit that has caused the newer Linux kernel versions to eat up laptop batteries.
Can Mercurial do that? Yes it can, they added a bisect command to Mercurial. http://www.selenic.com/mercurial/hg.1.html#bisect. But I want you to compare that to the Git bisect command. http://kernel.org/pub/software/scm/git/docs/git-bisect.html. It's not really fair to compare the documentation because the Git documentation is much more verbose. You will notice though, that the Git bisect has quite a few more features and is much more powerful. The git-bisect start command in particular is incredibly powerful and when used properly can greatly speed up the bisection process by skipping over commits that are not necessary to check. Of course, those extra features make the Git command much more complicated, and it requires a deep understanding and mastery of Git to actually take advantage of all that power.
And that, in general, is the key difference between the two. For the vast majority of developers who will never learn fancy and esoteric things, there is effectively no difference between Mercurial and Git. But when you really get down to the brass tacks a bearded Linux dude can easily come up with many reasons to look down at Mercurial.
It's an older posting, but I once read a blog that compared Git and Mercurial thusly: "Git is like MacGyver whereas Mercurial is like James Bond." I think it's an apt description. Mercurial is smoother, gets the job done efficiently, and easier on the eyes, so to speak. However, Git does give you the power to do all sorts of crazy duct-tape hacks around it for the obscure situations when nothing else will work.
I think to myself, "I want to fuck around with some test files..."
in hg, I create a new repo, pull from some base repo, test away. manually update anything I might want back to base repo.
in git, I branch base repo, checkout testing branch, test away. can merge anything I might want (-p) back to base repo.
I think I'm seeing the utility of the branch mechanic that Scott was talking about at the local level. Does the branch extension do anything like branch/checkout/(modify)/merge ?
The other major difference between Git and Mercurial is Git's staging area. Most people don't understand the staging area because you don't have to in order to achieve basic usage. Mercurial users basically see it as an extra unnecessary step. The whole thing is basically the git-add command. In Git you add things before you commit them. 99% of the time when you are making a commit you just want to take all the changes you currently have and commit them, even if they are new files or changes to existing files. To do this in Git you have to do git add --all; git commit -m "message". You can do the command git commit -a, but that will only add and commit changes to existing files without adding newly created files. As far as I am aware Hg doesn't have a staging area, you just commit, and it commits everything.
Why have this staging area? Because if you actually use it, which most people don't need to do most of the time, you can do crazy shit. For example you can do git-add -i to perform an interactive add. Let's say you have a file with a class and you added five methods to it. With interactive add you can pick and choose exactly which lines go into the staging area. You can add some of the methods to the staging area to be committed while leaving the others alone. Why is this useful? What if three of the methods are for feature X and two are for feature Y. Now feature X and Y will be in completely separate commits, making it easier to add, remove, or merge those features atomically.
The git commit command, with no options, takes the staging area, creates a new commit from it. It moves HEAD to that commit, and also moves the current branch to that commit. This allows you to craft your commits without the text editor. I don't know if there's an extension to Mercurial that adds this feature. It's something almost nobody takes advantage of, and it causes most people a lot of extra typing in Git. But if you actually use it, you won't be able to live without it.
It's actually not that terrible. Most commercial chocolate ice cream is just the leftover ice cream starters from other flavors, blended together with chocolate. The chocolate is usually so strong that it overpowers every other flavor, so nobody notices.