This forum is in permanent archive mode. Our new active community can be found here.

DVCS and You! (and ice cream)

edited June 2011 in Technology
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!"

Comments

  • edited June 2011
    Whether you prefer Mercurial or Git is up to you. It's definitely slightly more user friendly. I prefer Git feature-wise mostly because Mercurial forces all branches to be shared where Git lets you have local branches.

    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
    Post edited by Apreche on
  • edited June 2011
    This response is in no way trying to nitpick the responses. I'm just looking for a more clear understanding.
    Mercurial forces all branches to be shared where Git lets you have local branches.
    How does mercurial disallow local branching? What an oddly phrased question I've made. Let me try again:

    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?
    Also, while its user friendliness is lacking,
    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 :)
    Git is technologically superior under the hood.
    I've heard this, but I haven't read any lay explanations as to why. Can anyone provide something like that? I'd like to understand if those improvements referenced actually help the developer (like features that benefit from a software engineering standpoint, e.g. noted local branching difference) or if they are merely tweaking the most out of your processor/ram.

    EDIT:
    Git is good enough for the Linux Kernel, so it's good enough for you.
    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.
    Post edited by Byron on
  • edited June 2011
    First of all the matter of mercurial branching. Let's say you and I setup Mercurial on both of our computers. We start doing some pushing and pulling to each other. Then I create a branch. Now you pull from me. The branch appears on your repo! That's why there is a local branch Mercurial extension because by default all branches are shared. If you clone a repo with ten branches, you now have ten local branches. In Git everything is local except what you explicitly share. You don't need any extensions because it does everything already.

    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.
    Post edited by Apreche on
  • edited June 2011
    The local branching argument makes sense. I think for Mercurial, the equivalent solution is often to create a new repository copying some other repository instead of creating a branch. Share "some other repository", do not share "local repository", merge between as desired. However, this effort is a function of the discipline of the developer rather than a feature built into the VCS.

    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.
    Post edited by Byron on
  • But the question of alternative github-like services still remains, as well as comparisons of github vs bitbucket at a higher level than git v. hg.
  • But the question of alternative github-like services still remains, as well as comparisons of github vs bitbucket at a higher level than git v. hg.
    Very true. Github != Git.
  • Version control is important for writers as well. I use Dropbox. While not as elegant as using, for instance, Git, saving to dropbox gives me easy access versioning as well as hot backups to the cloud and multiple machines.
  • edited June 2011
    I didn't know Dropbox uses versioning. I've had a ton of friends try to get me on there because they wanted to share pictures or PDFs.

    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.
    Post edited by Byron on
  • edited June 2011
    Mercurial and Bitbucket might be awesome, but I have no reason to ever bother looking at either because I use git and github.

    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.
    Post edited by okeefe on
  • First of all the matter of mercurial branching. Let's say you and I setup Mercurial on both of our computers. We start doing some pushing and pulling to each other. Then I create a branch. Now you pull from me. The branch appears on your repo! That's why there is a local branch Mercurial extension because by default all branches are shared. If you clone a repo with ten branches, you now have ten local branches. In Git everything is local except what you explicitly share. You don't need any extensions because it does everything already.
    I consider this a mere difference in philosophy between the two apps. Mercurial has a lot of stuff that it does in "extensions," but most of these extensions are part of the standard distribution anyway.
    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.
    Mercurial also does SHA hashing of everything you put in, so this point is a bit moot.

    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.
  • edited June 2011
    Here's a great example of the kind of powerful thing you can do with Git.

    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.
    Post edited by Apreche on
  • 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.
    The ironic thing is that Mercurial was actually written by a Linux kernel hacker who himself admits that he "can't wrap his head around Git" and uses a Git->Mercurial bridge to do his kernel development. Supposedly Linus himself said that if Mercurial was around a little earlier, he would've used it instead of creating Git. (It's not the first time he's said something like this -- he has also stated that if FreeBSD was around earlier he would've used it and never would've started on Linux).

    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.
  • 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 remember reading that same article, but it didn't dive much into technical details as I recall. It sort of stuck to the high level usability argument.
  • Git also has a really simple view of the world. Once you understand it, working with git is a lot easier.
  • Supposedly Linus himself said that if Mercurial was around a little earlier, he would've used it instead of creating Git.
    Obviously. He created Git because he couldn't use Bitkeeper anymore, and every other viable option sucked. If Mercurial existed, he could have just used it without having to go through the trouble of making Git.
  • Supposedly Linus himself said that if Mercurial was around a little earlier, he would've used it instead of creating Git.
    Obviously. He created Git because he couldn't use Bitkeeper anymore, and every other viable option sucked. If Mercurial existed, he could have just used it without having to go through the trouble of making Git.
    Quite true. I for one liken the Mercurial vs. Git debate to be like arguing over different flavors of ice cream. Everyone (assuming you don't have dietary restrictions keeping you from eating it) loves ice cream, but some people prefer chocolate while others prefer strawberry. Still, it's all ice cream, so it's all good.
  • edited June 2011
    Okay, so after being cosmetically entrenched in Mercurial for some time and learning git more recently, I've found one thing about git that I'm not sure how to do in hg:

    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.
    That's why there is a local branch Mercurial extension because by default all branches are shared.
    Does the branch extension do anything like branch/checkout/(modify)/merge ?
    Post edited by Byron on
  • Does the branch extension do anything like branch/checkout/(modify)/merge ?
    I have no idea.

    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.
  • some people prefer chocolate
    Knowing the terrible secret of most chocolate ice cream, I prefer other flavors in most cases. ;^)
  • edited June 2011
    Knowing the terrible secret of most chocolate ice cream, I prefer other flavors in most cases. ;^)
    Terrible secret? What is ... No, no. I don't want to know.
    Post edited by zehaeva on
  • edited June 2011
    Hg doesn't have a staging area, you just commit, and it commits everything.
    Actually, I regularly use "hg commit -m comment [file list]" to atomically specify which files I want as part of that commit, and continue with related commits together. git improves this with the -p option, allowing finer granularity for specific diffs in each file so that related pieces of files can be lumped together. Otherwise I agree with those saying that the staging area is sorta just a name a formalization for a concept that already exists elsewhere.
    Post edited by Byron on
  • some people prefer chocolate
    Knowing the terrible secret of most chocolate ice cream, I prefer other flavors in most cases. ;^)
    I do not know said terrible secret... Probably for the best, although chocolate isn't one of my favorites (and when I do get it, I usually get it from an organic ice cream place near my home).
  • I do not know said terrible secret
    Don't worry, I'm here to help!

    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.
  • 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.
    Wait, so its like ice cream flavored ice cream, plus chocolate?
  • Don't worry, I'm here to help!

    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.
    ... Thanks? It doesn't seem so horrible. A bit weird but not horrible.
  • ... Thanks? It doesn't seem so horrible. A bit weird but not horrible.
    Try "real" chocolate ice cream, and it tastes waaay different from "chocolate" ice cream produced in this manner.
  • edited June 2011
    "Real" like from where? Smaller producers? Ben & Jerry's? Names man, I need names!
    Post edited by zehaeva on
  • I do not know said terrible secret
    Don't worry, I'm here to help!

    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.
    That might explain why my wife thinks the regular chocolate ice cream from the organic place near our home I mentioned earlier tastes "weak" to her -- since it's probably not made from leftovers, the maker probably doesn't dump as much chocolate flavoring into it, so it doesn't taste quite as "chocolately." Fortunately, the "Darth Chocolate" flavor they have is very strongly flavored -- enough to satisfy her.
  • With that said, I still like most chocolate ice creams. Especially when mixed with peanut butter.
Sign In or Register to comment.