Mercurial vs Git; it’s all in the branches

I have been thinking on comparing Git to other SCM’s. I’ve analyzed several of them and so far I’ve only done the comparison with Monotone (here). Nowadays it’s pretty clear that Git is the most widely used DSCM out there, but Mercurial is the second. So, here is a comparison between Git and Mercurial.

Note: I’m a long-time advocate of Git, and a contributor to the project, so I am biased (but I hope my conclusions are not).

Google’s analysis

So, let’s start with Google’s analysis where they compared Git with Mercurial in order to choose what to use in Google Code. Here I’ll tackle what Google considered to be Mercurial advantages.

Learning Curve. Git has a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users. Mercurial’s documentation tends to be more complete and easier for novices to read. Mercurial’s terminology and commands are also a closer to Subversion and CVS, making it familiar to people migrating from those systems.

That is a value judgement and while that seems to be the consensus, I don’t think Git is much more difficult than Mercurial. In the last Git user survey, people answered the question ‘Have you found Git easy to learn?’ mostly as ‘Reasonably easy’ and few as ‘Hard’ or ‘Very Hard’. Plus, the documentation is not bad, as people answered ‘How useful have you found the following forms of Git documentation?‘ very positively. However, it’s worth noting that the best documentation is online (not the official one) (according to the survey).

Regarding the amount of commands, most of them can be ignored. If you type ‘git’ only the important ones would be listed.

The last point is that Mercurial is easier for people migrating from Subversion and CVS; that is true, but personally I don’t consider that’s a good thing. IMO it’s perpetuating bad habits and mental models. For people that have not been tainted by CVS/Subversion, it might be easier to learn Git.

Windows Support. Git has a strong Linux heritage, and the official way to run it under Windows is to use cygwin, which is far from ideal from the perspective of a Windows user. A MinGw based port of Git is gaining popularity, but Windows still remains a “second class citizen” in the world of Git. Based on limited testing, the MinGW port appeared to be completely functional, but a little sluggish. Operations that normally felt instantaneous on Linux or Mac OS X took several tenths of a second on Windows. Mercurial is Python based, and the official distribution runs cleanly under Windows (as well as Linux, Mac OS X, etc).

That was probably true at the time, but nowadays msysGit works perfectly fine. There has been a lot of work to make Git more portable, and the results have been positive.

Maintenance. Git requires periodic maintenance of repositories (i.e. git-gc), Mercurial does not require such maintenance. Note, however, that Mercurial is also a lot less sophisticated with respect to managing the clients disk space (see Client Storage Management above).

Not any more.

History is Sacred. Git is extremely powerful, and will do almost anything you ask it to. Unfortunately, this also means that Git is perfectly happy to lose history. For example, git-push –force can result in revisions becoming lost in the remote repository. Mercurial’s repository is structured more as an ever-growing collection of immutable objects. Although in some cases (such as rebase), rewriting history can be an advantage, it can also be dangerous and lead to unexpected results. It should be noted, however, that a custom Git server could be written to disallow the loss of data, so this advantage is minimal.

This was an invalid argument from the beginning. Whether history is sacred or not depends on the project, many Git projects have such policy, and they don’t allow rebases of already published branches. You don’t need your SCM to be designed specifically to disallow your developers to do something (in fact rebases are also possible in Mercurial); this should be handled as a policy. If you really want to prevent your developers from doing this, it’s easy to do that with a Git hook. So really, Mercurial doesn’t have any advantage here.

In terms of implementation effort, Mercurial has a clear advantage due to its efficient HTTP transport protocol.

Git has had smart HTTP support since quite some time now.

So, of all the supposed advantages of Mercurial, only the learning curve stands, and I already explained, it’s not that strong of an argument.

IMO Google made a bad decision; it was a matter of time before Git resolved the issues they listed, and in fact Google could have helped to achieve them. Now they are thinking on adding Git support; “We’re listening, we promise. This is one of the most starred issues in our whole bugtracker.” (Update: already done). My recommendation to other people facing similar decisions is to choose the project that has a brighter future, chances are the “disadvantages” you see in the present would be resolved soon enough.

stackoverflow’s comparison

The best comparison I’ve seen is the one on stackoverflow’s question Git and Mercurial – Compare and Contrast, the answer from Jakub Narebski is simply superb.

Here’s the summary:

  • Repository structure: Mercurial doesn’t allow octopus merges (with more than two parents), nor tagging non-commit objects.
  • Tags: Mercurial uses versioned .hgtags file with special rules for per-repository tags, and has also support for local tags in .hg/localtags; in Git tags are refs residing in refs/tags/ namespace, and by default are autofollowed on fetching and require explicit pushing.
  • Branches: In Mercurial basic workflow is based on anonymous heads; Git uses lightweight named branches, and has special kind of branches (remote-tracking branches) that follow branches in remote repository.
  • Revision naming and ranges: Mercurial provides revision numbers, local to repository, and bases relative revisions (counting from tip, i.e. current branch) and revision ranges on this local numbering; Git provides a way to refer to revision relative to branch tip, and revision ranges are topological (based on graph of revisions)
  • Mercurial uses rename tracking, while Git uses rename detection to deal with file renames
  • Network: Mercurial supports SSH and HTTP “smart” protocols; modern Git supports SSH, HTTP and GIT “smart” protocols, and HTTP(S) “dumb” protocol. Both have support for bundles files for off-line transport.
  • Mercurial uses extensions (plugins) and established API; Git has scriptability and established formats.

If you read the whole answer you would see that most of the differences between Mercurial and Git are very subtle, and most people wouldn’t even notice them, however, there’s a fundamental difference that I’ll tackle in the next section: branches.

It’s all in the branches

Update: here’s a new blog post that goes deeper into the branching model differences.

Let’s go directly for an example. Say I have a colleague called Bob, and he is working on a new feature, and create a temporary branch called ‘do-test’, I want to merge his changes to my master branch, however, the branch is so simple that I would prefer it to be hidden from the history.

In Git I can do that in the following way:
git checkout -b tmp-do-test bob/do-test
git rebase master
git mergetool # resolve conflicts
git rebase --continue
git mergetool # resolve conflicts
git rebase --continue
git checkout master
git merge tmp-do-test
git branch -D tmp-do-test

(Of course this is a simplified case where a single ‘git cherry-pick’ would have done the trick)

Voilá. First I created a temporary branch ‘tmp-do-test’ that is equal to Bob’s ‘do-test’, then I rebase it on top of my master branch and resolve the conflicts, Git is smart enough to notice that by not picking any line of Bob’s last commit, the commit should be dropped. Then I go to the master branch and merge this temporary branch, and finally remove that temporary branch. I do variations of this flow quite a lot.

This is much more tricky in Mercurial (if possible). Why?

hg branch != git branch

In Git, a branch is merely one of the many kinds of ‘refs’, and a ‘ref’ is simply a pointer to a commit. This means that there’s nothing fundamentally different between ‘bob/do-test’ or ‘tmp-do-test’, or ‘master’, they are all pointers to commits, and these pointers can be easily be deleted, renamed, fetched, pushed, etc. IOW you can do pretty much whatever you want with them.

In Mercurial, a branch is embedded in a commit; a commit done in the ‘do-test’ branch will always remain in such a branch. This means you cannot delete, or rename branches, because you would be changing the history of the commits on those branches. You can ‘close’ branches though. As Jakub points out, these “named branches” can be better thought as “commit labels”.

Bookmarks

However, there’s an extension (now part of the core) that is relatively similar to Git branches, the bookmarks. These are like Git ‘refs’, and although they were originally intended to be kept local, since Mercurial 1.6 they can be shared, but of course, both sides would need this extension enabled. Even then, there is no namespace to delimit say, my ‘do-test’ bookmark from Bob’s ‘do-test’ bookmark, like Git automatically does.

Future

In the future perhaps Mercurial would add namespaces to bookmarks, and would make the bookmarks and rebase extensions part of the core. At this point it would be clear that traditional Mercurial branches didn’t make much sense anyway, and they might be dropped. And then of course there would not be much practical difference between Mercurial and Git, but in the meantime Git branches are simply better.

Conclusion

The conclusion shouldn’t be that surprising; Git wins. The way Git deals with branches is incredibly simple, and yet so powerful, that I think that’s more than enough reason to crush Mercurial in respect to functionality. Of course, for simple use-cases they are the same, and perhaps Mercurial would be easier for some people, but as soon as you start doing some slightly complicated handling of branches, the “complexity” of Git translates into very simple commands that do exactly what you want. So, every workflow is supported in Git in a straight-forward way. No wonder most popular projects have chosen Git.

Projects using Git: Linux Kernel, Android, Clutter, Compiz Fusion, Drupal, Fedora, FFmpeg (and libav), Freedesktop.org (X.Org, Cairo, D-Bus, Mesa3D), GCC, GNOME, GStreamer, KDE, LibreOffice, Perl5, PulseAudio, Qt, Ruby on Rails, Samba, Wine, VLC

Update: Eclipse is also using Git for a bunch of projects.

Projects using Mercurial: Adium, Go Programming Language, Mozilla, OpenJDK, OpenSolaris, Pidgin, Python, Vim

About these ads

225 thoughts on “Mercurial vs Git; it’s all in the branches

  1. Agreed perfectly. I make this exact same point when comparing git to mercurial. People tend to underestimate the problems with mercurial’s branching model. To most novices who are just getting into DVCS, a common thought it ‘oh – that’s a very complex situation, we’ll never need that’. Turns out that for any real-life project with multiple developers, sooner or later there will be a situation when the branching model & workflow will need to be changed; and this is very git shines.

    As a side node, many of the commonly listed ‘advantages’ of hg over git are view of past. GIT is very much usable and stable on Windows. Git’s documentation is quite good now. The GUI support is decent enough now.

    Personally, we started using hg for one of our projects early on (there were 3 devs working together). I readily admit that I found hg to be very easy to transition to from Subversion. I especially admired hg’s Windows support and how flawlessly its simple GUI worked.
    On the other hand, my first experience with GIT was very frustrating. This was on a project having developers working across Windows/Mac OS X/Linux landscape. The imminent problems that arise out of Windows/OSX environments – mainly because of misconfiguration; really bogged us down initially. However, once these got sorted out , we eventually got hang of git. I’d say these problems are real, but definitely nothing major to hold against git. The real eye-opener was working on multiple different workflow styles using git – and the need to create branches. The ease and intuitive way in which I saw git handling branching really sold me on to it.

    These days, I almost always first try to use git for a project. The only time I consider hg is when the project is decidedly too simple to need any amount of decent branching in future (which is very infrequent)

  2. @Éric Well, the first link doesn’t really say much against git, the second one says permanent branches are possible, but complains about the “mindset encouraged by the git documentation”; I say he got it wrong. What you do with branches is up to you.

  3. Quite interesting read, but I’m afraid you’re preaching to the converted. I’m rather happy with Mercurial, with little Git experience, I tend to agree to Google’s analysis, and I can’t really follow all the details of the pro-Git statements.

    Your example “It’s all in the branches” may be self-evident to Git users, but it is hardly sufficient to convice newbies of the merits of Git. In fact, what I see really scares me, in terms of “history is sacred”.

    There is another important point you do not mention at all: Integration with other tools and processes. What about Git plugins for Eclipse, Jenkins, TeamCity, Maven, just to name a few?

    For example, for a long time I preferred to stick with Subversion, mainly because the HgEclipse integration was barely usable. (But I’m now happy with the current version of MercurialEclipse.)

    So even if I came to see the advantages of Git (which I currently don’t see), I’d carefully evaluate EGit and other integrations before even thinking about starting a new project with Git instead of Mercurial.

  4. XCode4 now include native GIT support. This is not so significant due to being Apple, but that “A major recognizable developer community tool supports GIT”. GIT didn’t need this recognition, but in having it, some “friction” is reduced, giving the end-developer more choice of tools and compatibilities.

    I wanted to point out a reason (now gone) that had kept me using SVN — this, and I don’t know how to make GIT run without scripting :)

    I regret if I’ve hijacked somewhat this comment chain.

  5. @Harald My objective is not to convert newbies. Newbies don’t know squat.

    My objective is to show why Git is superior. So if you care about your own performance, and the one of your project, the choice is obvious. One allows you to do many things, the other one doesn’t.

    Regarding the integration with other tools, that has never been a requested feature, but there is some support:

    https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Editors_and_IDE_integration

    For big project to base their decision entirely on this would be unwise, as eventually Git would have support, and suddenly your project would have no reason to be using Mercurial.

  6. So I learned hg first and have used it for the last 9 months. It was easy.

    Now I’m on to git and while I’m finding it seems to be much more powerful than hg it is hard! (at least for me). It seems that every other day I run into some new issue I don’t know how to move past. I’m sure someday I’ll grok it all.

    I do see that git branches are pretty awesome and there doesn’t seem to be a truly similar feature in hg. By similar I mean even if there is branching in hg if it’s not instant then it’s not the same. Branching in git on my current project which has just short of 40k files is instant. Branching on hg takes minutes. That difference means using branches becomes second nature on git. You use them for anything. Someone says they need a small bug fix. Branch, fix, push, done in seconds. If you have to wait several minutes to branch you instead try to find workarounds.

    On the other hand, while I’ve read the parable of git which makes it clear there is no magic I still don’t understand exactly what each git command is doing. Just to show my ignorance, why is reverting so hard? in svn if I just want to throw away some local changes to a file as though I never touched it I go ‘svn revert file’. Same in hg. But not in git. In git it’s apparently ‘git reset –hard’. Why hard? That sounds so scary. Worse, after I did that and the did a ‘git pull’ I got errors I had never seen before. I’m sure some day I won’t feel like a complete idiot using git but not yet :-(

  7. > Branching on hg takes minutes.
    You seem to be confusing branching and updating (probably because of git, see http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/). hg branch is very fast; hg update may not be (lots of I/O).

    Regarding branching, Mercurial and git don’t have the same branches. See http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

    Hope this helps stopping the FUD about “cheap branching” :)

  8. @Éric By cheap branches we mean that you don’t even think about them, you can do as many as you want. In mercurial you can’t just create branches willy-nillingly, they are permanent, so you have to think hard before creating one, therefore expensive.

  9. Mercurial unnamed branches looks cheaper than git’ branches. Mercurial named branches are something else. Please read the article I linked to. :)

  10. @Éric That’s cheaper in the bad way… In the way that it’s not useful at all. Why would you want a dangling commit with no pointer to it? It’s like having a git branch called ‘mysterious_commit_number_3′, what is that commit for? When are you supposed to use it?

    The only time I can think about when you want to do that is when you want to tag a new version of an old release, say 1.4.1 when 1.5 has already been released. But in that case you can do the same in git; it’s called a detached HEAD. Those commits usually disappear on the next garbage collection, but if you have a tag pointing to them (or any other kind of ref), they don’t.

    Anyway, that’s a red herring, by branch of course we are talking about *named* branches, which is how everybody considers branches, and the only kind that is actually useful. Those are not cheap.

  11. Thank You for this blog post.

    Currently I’m deploying Git at work for one – Linux project. Since You need version control linux guys – show him Git. They will love this tool. Propose Git for Windows guys – they will ask You about Visual Studio integration.

    The problem is not absent Git SCC Providers – but their quality. In this particular case Mercurial wins.

    When Git Version Control Provider to Visual Studio open for me overloaded context menu (containing all which implement GitExtension or TortoiseGit) mercurial show me few most important actions. This is much more readable.

    + Native windows support
    + Straight forward, clear VS integration (by the way – it is sad but the best VS integration had Subversion right now – of course from non-commercial tools)
    + Build in Kerberos auth support (single-sign-on in windows domain using http:// protocol – something normal for Windows guys)

    mercurial rocks for Windows guys and the number of tickets for ntlm, SPNEGO, Kerberos, or abandoned fork of git with kerberos support – just scaring windows guys from using this tool. For Linux guys – it is perfect. They love command-line tools :)

  12. The Future arrived some time ago. The Rebase and Bookmark extensions are now included in the Mercurial core. The Mercurial bi-directional bridge to Git works quite well. And the named branches feature remains useful, so long as you don’t need to interoperate with Git. It’s the one feature of Mercurial that can’t survive the round-trip to and from a Git repository. More’s the pity. When will Git be improved to store branch history in change set records?

  13. > When will Git be improved to store branch history in change set records?

    Storing branch history in changeset record is a _poorer_ design – so no NEVER. Git will never store branch information WITHIN the changeset.

    That’s the whole point of having a separate branch head pointer object. Also , when branches are merged, the ‘Merge’ node in history explicitly indicates that.

    If you want to maintain branch history, no problem : git’s tree graph maintains that information by default – just as hg does.

    Where git differs is — it gives you an _OPTION_ to discard that information if you choose to. Mind you , the emphasis is on it being an _option_.

  14. @james You are missing the big picture; Git is already the unchallenged king of DVCS, period.

    If anyone needs to learn anything from anybody, it’s Mercurial from Git. They have tried hard to emulate Git’s branches with the bookmark extensions, but that can only take you so far. Eventually, they would have to accept that “named branches” in Mercurial are just dead wrong.

  15. > Git is already the unchallenged king of DVCS, period.

    I see… Because popularity always indicates value. Just like Windows is the unchallenged king of operating systems.

    It might help if you tried to look at Mercurial from the Mercurial user’s point of view. Has it occurred to you that a lot of people *like* Mercurial, they *like* the option to record a branch name in the history. Personally, I like the fact that Mercurial offers me at least 4 ways to handle branches, based on my personal preferences. I can use anonymous, light-weight branches, which I find useful for short-term branches. I can use bookmarks to get something medium-weight, that has a name and is longer lived. I can clone directories and use directories as branches without losing any features, something that I also find useful some times. Or I can have heavy-weight named branches. In contrast, git only offers one or maybe two types of branches depending on how you count. The one that git chose is not universally the one I want. I like that Mercurial gives me an option.

    There are other things that Mercurial users like about Mercurial. For example, Mercurial seems to put more emphasis on keeping your data safe. It is very difficult to lose data with Mercurial. Basically, the only Mercurial command that can destroy your data is “rollback”, and it is very limited. Anything else requires something like “rm -rf”. I have used Git a bit longer than Mercurial. I once lost data with Git, and I was not happy at all. I forget exactly what I did, but I lost a good chunk of committed work.

  16. @DanielC No, does not always indicate value, but it often does.

    And yes, I do have the power of empathy and I have put myself in the shoes of a Mercurial user, my conclusion is the one that I already mentioned: Mercurial branches are useless.

    1) anonymous light-weight branches:

    You can have the same in git with detached heads, or if you want to share the commits and there would be no other refs (like tags), use a temporary branch, like ‘tmp-experiment’. Since git allows you to remove branches, it’s up to you to decide if the branch is temporary or not.

    2) bookmarks:

    Same, you can use a name like ‘experiment’ and again, you decide how long does the branch lives.

    3) directories as branches:

    Same with git.

    4) named branches:

    There is nothing that Mercurial named branches can achieve that git branches don’t. I know what you are thinking: there must be some advantage, Mercurial guys are smart. Nope.

    Everything can be achieved with git branches, like, say you want to know all the commits that were part of branch ‘foo’ that are not part of the master branch (they would be labeled as ‘foo’ in mercurial);

    git log --oneline --decorate --graph foo^1..foo^2

    The fact of the matter is that you are lacking the imagination to realize that you can achieve exactly the same with git that you can do with mercurial, but in a much simpler way. And that’s where the popularity argument becomes important; Do you think git would be as popular as it is if it was possible to do something in Mercurial that wasn’t in git? Most likely no; people love git because you can do everything, despite the fact that sometimes it’s difficult.

    And finally, you can loose data with Mercurial or Git in exactly the same ways.

  17. Pingback: Pidgin picking the wrong DVCS again; Mercurial « Felipe Contreras

  18. I have little experience with both systems. I use git in a few of my side projects and mercurial in some others. Mainly because of the tools I use. I have notice in fact that git is a little harder to use, and that both systems achieve its goal (revision control) pretty well. Don’t get me wrong. I’m actually kind of inclined towards Git, but only because I have a geek inside of me and I feel like having to try or at least know the geekiest tool(arguably). The point that Google said the learning curve is important is right on the spot. I believe that in the real world, nobody (and by nobody I mean very few people) cares about the very advanced features. Like I can write “whatever” I like just by typing these 20 commands. Want a CMS? done. Want a backup tool? done. We want a version control system that works better and makes our lives easier and that’s it. In this case, both do the job. Git got very popular because it was developed by Linus Torvalds and also because of Github. I believe that’s the truth. Not because it is better, which is arguably true. When some thing gets successful is mainly because of some other reasons other than being the best one in its market. Windows, the IPhone and IE got very popular not for being the best. They got popular because they looked nice, a business strategy, or because people already had it, it was free and did the job. Even if it did it a little not well or a lot not well.

    Right now, I don’t really care about the advantages of Git branching, if I can clone my repo in mercurial and achieve the same thing with a different approach. With today’s HDD capacities and Internet & CPU speeds, I can clone a repository in a few seconds. And if the repo is really really big, I will not be branching as often because it means it’s a big project with a lot of people involved and I have a very specific role in the team. I should not be playing around with the code.

    Version control is a side task you have to do in order to write code. If you choose to use Git because it is better, great. If you use it because Linus wrote it and the Linux kernel is written using it, great. If you use it because you want to use Github, great. But I bet that very very few people use it just because they can branch in the way they can with Git and just because of that. Don’t get me wrong, I believe that there is usefulness is that feature. However, It’s not an overkill feature. There are still people out there using VSS. I feel for them.

  19. @carlos I don’t think so. I know many people that don’t like Linus, and don’t even know about GitHub, and yet love Git. Sure, there are many things that became popular not because of technical reasons, but that doesn’t mean _all_ of them do. Why do you think Linux has become so successful? Nobody knew Linus at the time; it’s because it’s great.

    Moreover, I do think that something that Linus Torvalds starts has higher chances of being great, not because he has magic hands, but because he knows what he is doing. I know you probably look at him as some mythical creature, but many people close to him in the Linux kernel mailing list constantly criticize his decisions, I myself have had discussions with him as well. If Git became popular, it’s not because people blindly trust what Linus does, it’s because he promotes a culture of no bullshit, open and honest communication, and so on. Also, he started it, but he didn’t develop it, there’s at least Junio C Hamano who has more contributions than him.

    Finally, I think you have not really grasped the real power of Git. I have known many people that have used Git for years, and only after long discussions on the benefits of things like ‘git rebase -i’, ‘git mergetool’ and ‘git send-email’ and so on they realize “man, how did I even live without them?!”. Do you use those tools?

  20. Here seem some knowledgeable git users, i’m just migrating to git from hg and cant figure out how to recursive ignore files in .gitignore. Basically i want to ignore all html files in my source directory (nested directories, each .pyx file has a corresponding annotated .html file)
    This was one regex pattern in .hgignore, but git doesn’t seem to be able to handle it at all with its platform-dependent fnmatch patterns

  21. @Pankaj It’s just *.html. And at least my version of git has it’s own fnmatch function that should be platform independent.

  22. thanks for your answer, but i don’t want to exclude the html files in my /docs/ (again recursive) directory, so this doesn’t work

  23. @Pankaj Well, find a glob pattern that does. Like src/*.html, or only have a .gitignore in the directory you want those removed. Or just enable them in the directory you don’t want them removed: !*.html. That’s clearly explained in ‘man gitignore’.

  24. Thanks a lot. A few minutes after my post i figured out that i could keep .gitignore file (with *.html) in src/ to exclude .html files in that directory only. And without this it can’t be done, src/*.html doesn’t recurse. I read man-page before but it was slightly confusing. Thanks again

  25. You prefer Git, I prefer Mercurial. We can rationalize our choices but in the end they both work just fine.

  26. @hohonuuli It’s not a matter of preference, what I can do with Git, I cannot do with Mercurial. I’m not rationalizing it, I’m explaining exactly why.

  27. Wow, you’ve almost turned me off from even wanting to learn git, you come across as a huge douche, and one without the genius requisite to serve as excuse. I think you overbill the flexibility of git as a feature. Sometimes carefully crafted simplicity, even by removal of choice, is a feature as well.

    It should also almost go without saying that if git’s deficiencies can/have been fixed with time, the same is also possible with hg. hohonuuli was right, you are rationalizing your choice, a rationalization is an explanation. To wit, while you explain you can do things in git you can’t do in mercurial, you aren’t necessarily convincing anyone else that they need those same features or workflow, or that they will somehow be unable to do their work if they select hg over git. Time saved upfront in learning can surpass time saved by better ‘features’ later.

    rationalize |ˈra sh ənlˌīz; ˈra sh nəˌlīz|
    verb [ trans. ]
    1 attempt to explain or justify (one’s own or another’s behavior or attitude) with logical, plausible reasons, even if these are not true or appropriate

  28. One extremely important matter to think about when choosing any technology is the quality of the community around the technology. Now it in many ways seems that git company is exactly the kind whom with I wouldn’t want to spend any more time than I have to.

    Also, given how much nicer mercurial is to use, the choice is quite easy.

  29. @Craig Y Ah, so you pick technologies based on personal feelings? Good luck to you.

    If you fix Mercurial’s deficiencies, you end up with Git.

    Regarding rationalizing, note the “even if these are not true”, that’s why you don’t rationalize your need to breathe air; you need to breathe air, it’s true, you are not making excuses. That’s why I’m not rationalizing my need for Git; it allows me to do things other SCM’s don’t, that’s the truth.

    And you are wrong regarding the learning curve. By your logic, notepad is better than vim, because it takes some time to actually get something done with vim. You are missing the point; Mercurial has a limit to what you can do, Git goes beyond that limit.

    @ab123 The community around Git is huge and amazing. There’s even companies that dedicate 100% to give support for Git. Not to mention the work by people like Scott Chacon who constantly creates presentations with the latest Git tricks, plus screen-casts, interesting software, etc.

    I also have a blog where I follow what’s happening in the web regarding Git.

    http://gitlog.wordpress.com/category/links/

  30. Notepad is better than VIM, if Im planning to roll out a simple text editor to non technical users within a company. Your analysis is based purely on features. Sure, the plugins will get better for Git. So am I supposed to put my code on an FTP server until then? “Best” is a relative term, best to whom? Best for what? I actually agree with you in that git is superiour in terms of features and design. If somebody could create a simple wrapper for git, allowing you to turn it into different modes (like client-server, or simple DVSC), perhaps there wouldn’t be any argument from either side?

  31. It is not that Hg is bad… it is just that Git is doing it slightly better. Git and Hg are better than the rest… So now when you have the choice, don’t go for second best…

    Git has a better storage model than Hg. Hg developer knows that and they try to deal with the problems by storing a new full copy when the content of the deltas exceed a certain level.
    Git is simply storing full copies and no deltas and it gives better and completely linear performance and less code to maintain with less risk for corruption of your data. Git run into a space problem here that is dealt with with by repacking, which also give a better performance for subsequent accesses as the number of open files are reduced.

    For me, and I’m not alone, the storage model is by far the most important thing. If the storage model is not right, it is very difficult to get the rest right. And even if you do, you are still having a less safe and less performing platform. If you care about you data, you use Git.

    Caring about integration with IDEs and other environments is basically silly. You use your DVCS for a variety of projects and not all use the same IDE and some don’t use IDE at all. That means you need to learn how the DVCS work without IDE integration, so learning it with integration is just a waste of effort anyway. If you argue that the integration saves time… think again…

    Martin

  32. @martin pettersson How do you know the developers on the projects we work on use a variety of IDE’s? Thats news to me, could you please let me know who they are? In a corperate enviroment these sorts of things ARE standardised, so that integration DOES save time. It can be documented, the core people educated, so somebody new coming in can get started very quickly.

    @FelipeC Well then Notepad wins over VIM, Paint wins over GIMP, Java wins over any other programming language, and your article is pointless….obviously.

  33. Hey Ben
    I’m also a slave under standardisation, believe me, but even if you only use one single IDE in your company, you also produce material that deserve version control from outside that IDE.

    Having a history as a consultant, I have been expected to use whatever tools the customer tells me to use.
    I’m having a full time employment right now, in a assembly/manufacturing business, the projects I work with have a large number of different systems with completely different environments for the software development.
    If you asked our IT department, a few years ago, they would say that all in house produced software is created using Visual Studio and VB.
    They would show you a list of “corporate standard software” and tell you that if it is not in the list, it is not allowed. They (former idiot IT manager) even had the intention of stopping our production lines until we removed all software not on the above mentioned software list which would be impossible of course.
    (this had nothing to do with licenses, we keep our software properly licensed)

    Since then I have had monthly meetings with IT department, and also got a new IT manager. We work together in some projects and mutual understanding is much better.

    So what once was an illusion of a situation with “one corporate standard IDE” turned out to be a reality with a great variety of environments used for different purposes and introduced during different times in history.

    That’s why you should learn your DVCS without the integration.

  34. I’m a simple man, who likes simple tools. Recently, me and my fellow developers decided to migrate our code from subversion to something with better branch/merge support, so we’d stop stepping on each other’s toes. The choice boiled down to two candidates – git or mercurial. We found tons of online documentation / tutorials for both packages, but overall git seemed more… complicated than what we needed. Nothing major, just little things like having to do “git add” or “git commit -a” to include our file changes in a commit (what the hell else would I be committing?), having to make “local tracking branches” whenever I clone on another workstation, etc. Mercurial, on the other hand, was stupidly simple to get started with. After browsing hginit.com or a half hour or so, we had a test repository set up, and later that afternoon we had migrated our entire code base to a mercurial repository on Google Code. We’ve been really happy with mercurial so far; we can maintain separate stable/development branches, and do experimental work on clone repositories with minimal effort (and a minimal set of commands to memorize). I don’t personally see how git could give us any further advantage. I’m sure for your purposes, you need the extra power and flexibility provided by git, but that doesn’t mean that *everyone* shares your same needs.

  35. @FelipeC: or maybe he *does* know what he’s missing.
    I’ve used Git a fair bit by now, and I know exactly what I’m missing when I use Bazaar instead.

    And I love it. The “more power is always” good argument is a fallacy. If you take that to extremes, then even Git is a crippled tool. The only tool that gives you free, unlimited control is *no version control at all*.

    Most of your arguments come down to “Git and Hg do things in different ways . I have some anecdotal evidence that someone, somewhere, were able to design their workflow to fit Git’s way of doing things, and therefore Git’s way is superior”.

    The important question is not “which tool gives me the most freedom to do what I like”, but rather “which tool allows best allows me to best version control my software” And constraints (don’t let me muck up my own history) and usability (make it easy for me to correctly keep my code version-controlled) are important features. Of course, so are a lot of other things. But what you’ve shown is not that Git is a better DVCS than Hg, but merely that Git is a better Git.

    That’s not surprising. But it’s not useful either.

  36. @jalf What I’ve shown is that Git is better than Hg, because every single thing that Hg does, you can do the same with Git, and it’s not more complicated.

    When everything else remains constant, more power is better. Thus Git is better.

    Show me a single command that is easier in Hg than it is in Git.

  37. “the branch is so simple that I would prefer it to be hidden from the history” If this is the reason you consider git to be superior, you’ll pardon those of us who prefer hg if we don’t jump on your bandwagon. You’ve gained no particular power, only the ability to pretend that a branch was always a single commit (and if someone really needs this capability, you can do it just as easily in hg with mq, arguably easier).

    Would it be too rude to point out that this “killer feature” is one of the few areas where SVN is actually just as easy to use as either hg/git? Enough so that some of us consider it a fundamental flaw in SVN’s (lack of) merging model? (I know, I know… svn doesn’t have any other option for merging… but the point remains)

  38. @Kiru mq does nothing to solve the issue I am talking about: having a namespace for the remote branches.

    If you prefer to not use certain killer features, that’s up to you, but for the rest of us not having this feature is unacceptable.

  39. It would probably do the git community some good to quit looking down on anyone who isn’t a banner-waving kool-aid-chugger. Geek snobbery isn’t endearing, and hasn’t been since sophomore year.

    Your post wasn’t actually talking about using namespaces for remote branches, aside from a single small sentence at the end of a shortish paragraph. You could just as easily say that the point of your post was “IMO Google made a bad decision.” Your “killer feature” that you actually spent three quarters of your post talking about is easier to work with in svn. Perhaps you could write another one that communicated what you intended.

    Your claim on mercurial was that your merge of bob’s changes was “much more tricky in Mercurial (if possible). Why?” Well… it is neither tricky nor impossible, even with the usual hg ‘branch’ layout…

    hg clone http://server/hg/master
    hg pull file-share/bob/bobs_stuff
    hg mq qimport -r X (whatever bob committed)
    hg qpop -r Y
    hg up
    hg qfold
    hg qfinish -a
    hg push

    I’m sure each line of your git-procedure above is equally obvious to you. This is, of course, assuming that one of the simpler formulas doesn’t handle the situation for you. (I’m personally fond of piping a diff into the import command, something I’m sure git can do with equal ease)

    Obviously some of the details can get messy right around the merge step (the qfinish in the hg case), but that is dependent on the underlying changes and the choice to combine them to one cset, not the tools involved.

    Since you seem to want to talk about “having a namespace for remote branches”, in spite of it being irrelevent to the majority of your posting, we can talk about that. You posted it in bold, but then apparently didn’t understand what it means to say “hg branch != git branch”. What happened here is an odd accident of history. SVN branches were used for two different purposes, and git took off with one usage of them, and hg codified around another. Here at my workplace, we’re still stuck on svn and use both types of branches, so perhaps this is more obvious to me than to users who used only one or the other.

    HG branches were modeled after ‘release branches’. Separated lines of development that ‘dead-end’ code. An example of use would be for code that has actually shipped to customers in a quality-controlled environment (like mine, I work in hardware), and they will want to inspect every single code delta from that point onward, until you convince them to take a new major release.

    If you want git-like branches in hg, use seperate repos. If you don’t like that idea, I suppose you could use bookmarks, but they’re not fully supported by all of the tools. Given the long series of things that git has added, I hope you won’t be too hard on hg for not being quite done with that.

    As an example of ways git still needs to work on it’s documentation… your #10 item on your most used command list does not actually appear anywhere in the user-manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual.html). Sure… a google search tells you what you need to know, but Microsoft could say the same thing.

  40. @Kiru You must not have read my post carefully.

    1. The title is “Mercurial vs Git; it’s all in the branches”
    2. The whole blog is building up to the comparison between Git and Mercurial branches (obviously hinted by the title)
    3. The post then explains that hg “bookmarks” are close to git branches, but without namespaces
    4. And ends up by explaining that if Mercurial adds namespaces to bookmarks (and perhaps adds them to the core), there would be no difference between Git and Mercurial

    In other words; Mercurial = Git – branch namespaces. I don’t see how it can be any more clearer. Maybe you don’t understand the concept of building up to a conclusion.

    Your example is still quite tricky, as 50% of the commands you are using are not part of Mercurial’s core. And even if you ignore that fact, you are ignoring the important part bob/do-test. IOW; the important part is not the rebasing, or the creation of branches, the important part is identifying bob’s branch and commits, and contrast them with your branch and commits. namespaces.

    You can try a more complicated example; create a “contributors” branch, merge the branch “bob/do-test”, then “alice/to-merge”, and finally rebase “rene/wip” dropping a few of the commits. Say each one of those contributors has 10 branches on their own personal repos, it would easily become impossible to visualize which branches are from whom. Scale to a few more repos, not only of contributors, but storage locations, and things would be completely unmanageable.

    And nobody asked for examples of ways git needs to work on its documentation, and I don’t know what is that “#10 item”, nor why would that be relevant for anything.

  41. “50% of the commands you are using are not part of Mercurial’s core”
    That really depends on how you define ‘core’. They’re included in the core application, but you do need to flip a switch to use them. A few posts ago on this blog, you listed the most used commands on your command line, #10 on that list is a git command that never appears anywhere in the manual. Personally, I consider this at least as inconvenient as needing to filp a switch to access the ‘hg mq’ commands.

    In the usual hg worldview, what would be branches in git are separate repositories. So your ‘bob’ namespace would probably be bob’s directory on a fileshare. You’re forgetting that in a normal hg organizational hierarchy, the complexity of merging starts and ends with “alternate storage locations”. When you consider this organization, “development branch namespaces” becomes much, much less of a ‘killer feature’, and more of a “oh… that’s interesting”. Since the git culture keeps everything in one large bundle, I agree that branch namespaces are an essential feature, but hg users simply aren’t going to feel the need for it.

    Your supposedly “completely unmanageable” case (that I happen to work with periodically in hg, and it’s quite manageable, actually) works rather well. It’s surprisingly easy to work with and visualize all of these changes. The rebasing of “rene/wip” imports will cause you a few problems, depending on how it’s used, but git is no better (as KDE discovered recently, when a few rebase addicts started mucking with their dev branches). If you do it properly, alternating merges and null-merges, it works pretty well with either git or hg.

  42. @Kiru If you need to flip a switch, it’s not part of the core. You might want to use a certain feature on a server, but the server doesn’t have that switch, so you are screwed.

    What does that other blog post has to do with anything? For starters, the #10 item on the list is ‘ls’, it has nothing to do with git. I assume that you are referring to ‘git br’, which is a personal alias. How is that a fault of git? You can alias anything on a shell; “alias foobar=’hg –version’”. Why would you even compare that to a mercurial extension? aliases are optional, you can have all the functionality of git without using them. That’s just a cheap red herring.

    The problem with having different local repositories for remote repositories is that you can’t easily see them all in one view, like you can with git. And then it becomes very difficult to see what goes where, and how to reorganize the commits.

    Maybe you think that case is “completely manageable” because you haven’t seen how well it can be managed in git. I am certain it cannot be easy, as I have tried.

    How about this challenge: you can I record videos of the same situation; 10 repositories, each with 10 independent branches, show them all. Then, pick on branch on each of the 10 repositories, and rebase them one after the other on top of the master branch. We’ll then see in which case it’s easier, and faster. Deal?

  43. Erm… this “switch” is configurable on a per-user basis. There is also nothing to it that would involve a remote server in any way. If you somehow had access to a command line, and not to the users ~/.hgrc file, you can also just add a switch to the hg commands to temporarily enable mq. This is not an issue, and your ignorance of hg is showing in your persistence on this non-point.

    Regarding your other blog post, perhaps I misunderstood what the numbers meant. I thought they represented frequency in the second list, and the command that I’m talking about is ‘git clean -fxd’.

    Now wait a minute… you were the one who claimed that your scenario was “completely unmanageable” (in hg?). I was the one who said it was quite manageable, and that I handle such complex merge scenarios on a regular basis, please don’t rewrite history here. (damn rebase addicts… ;)

    Your challenge scenario would be rather tedious, frankly. Not to mention trivial in hg. The “proper” way of doing that in hg is to repeat the one-liner `hg export -R remote-repoZ -r X:Y | hg import -R local-repo -m “rebase X:Y” -` for each ‘rebase’ for each branch. Two bash loops with a few arrays could handle the whole thing. I’m relatively confident that git has a similar one-liner for this purpose.

  44. @Kiru No, it’s not, you need support in the server in order to push bookmarks.

    http://mercurial.selenic.com/wiki/BookmarksExtension

    That’s the only way you can reproduce my use-case of bob’s do-test branch, or any of the other examples I mentioned, because the branches are temporary.

    Regarding ‘git clean’, it’s clearly defined in the documentation:

    http://www.kernel.org/pub/software/scm/git/docs/

    http://www.kernel.org/pub/software/scm/git/docs/git-clean.html

    My challenge is tedious only in mercurial, not in git, which is the point.

  45. I’ve come to believe that you are not taking this conversation seriously. The history of this conversation is available for all to see, but I’ll recount it for you anyways.

    In the original post you claim that a particular recipe is difficult/impossible to duplicate in hg.
    At 23:12 (29th) I introduce a simple hg recipe using mq that essentially accomplishes the same thing.
    You counter “Your example is still quite tricky, as 50% of the commands you are using are not part of Mercurial’s core” Note “commands”… none of which have anything to do with bookmarks.
    17:27 (1st) I point out that mq _is_ part of the core, and simply has to be toggled on.
    At 12:23 (2nd), you profoundly misunderstand how things are configured in hg
    I correct your misunderstandings at 16:44 and point out that this is not a productive line of questioning for you.
    Now you claim you were talking about “bookmarks”, not the “commands” that you specifically brought up as the problem.

    Sorry… but it’s hard to take your argument seriously when you keep switching what you’re talking about.

    Then there’s this… “That’s the only way you can reproduce my use-case of bob’s do-test branch, or any of the other examples I mentioned, because the branches are temporary.” Actually, I talked about how you would do this in mercurial several posts ago, you simply ignored it. You’re right that a feature that’s absolutely required due to git’s usage patterns is required in git. You’re wrong for pontificating that therefore it’s required everywhere else.

    “My challenge is tedious only in mercurial, not in git, which is the point.” I had to laugh at this. I gave you a trivial one liner that handles it, another single line would generate the X::Y pairs to feed that line, so three lines of bash script (all of whose lines are trivial to understand) handles your supposedly difficult problem. “Tedious” means incredibly boring if it was done manually without this script. I’m not sure there is a universe in which 10(repos)*10(heads) rebases are not going to be tedious unless scripted. The fact that you thought this was going to be a difficult challenge speaks volumes about your ignorance of hg in actual use.

    Given that you’ve ignored my points, made sweeping statements on hg from a position of willful ignorance, and completely ignored the actual topic of conversation in several cases… I guess I’m not sure what can productively come out of this conversation.

  46. @Kiru You are twisting the conversation:

    First of all mq is an extension, I brought that up to argue that the commands were tricky, but IMMEDIATELY after that I went back to the IMPORTANT part you were ignoring; bookmarks.

    Your example is still quite tricky, as 50% of the commands you are using are not part of Mercurial’s core. And even if you ignore that fact, you are ignoring the important part bob/do-test. IOW; the important part is not the rebasing, or the creation of branches, the important part is identifying bob’s branch and commits, and contrast them with your branch and commits. namespaces.

    I am not switching what I am talking about, you are just not listening.

    And since you are not going to accept the challenge, which you already admit is tedious to do in mercurial, I say that’s admitting defeat. Git branches are superior. Period.

  47. No… making a video doing the same damn thing 10 times is tedious. I’m curious why you think it wouldn’t be with git. If I challenge you to sort your T-shirts by color, then mix them, and repeat 10 times… that’s not “a challenge”, it’s a stupid exercise in tedium that doesn’t prove anything. If you knew ANYTHING about actually using hg, you’d realize that this is just as pointless.

    Regardless… you’re obviously not listening, and I’m tired of repeating myself to someone who obviously isn’t interested in actually reading what I’m typing.

    I had originally intended to take this in a more productive direction, focusing on the real respective weaknesses of the two systems (cset selection differences, cherry-pick+merge collision issues, detached-head oddness, failed merge cleanup issues), but it’s fairly obvious that you would not be a productive person with which to have that conversation.

    Good bye, and good luck in your git’ting.

  48. I would like to share some experience here, if you don’t mind.

    In the company I work for there are dozens of small projects. The usage of DVCS-s of Hg/Git is about – 67%/33%. Why people prefer Hg?

    I consider Git is more convenient for development. However, Mercurial has more user-friendly interface (especially for Windows developers), it is more easy to re-educate people to use Hg. Whereas Git is harder to start using. “Software is the key.” (C) Bill G.

    Couple of days ago I have re-educated 5 developers to use Mercurial, which used SVN only all their life. And you know what? That was and still painful! They still blame me. They still think SVN is way better than Mercurial. And they still hard to maintain their own repositories.
    I think I would go crazy if I decided to use Git for our project. They would, probably, kill me even before their first branch.

    Yes, git is more convenient for development. But Mercurial is much better to begin DVCS experience.

  49. Here we have two systems that has almost identical user interfaces on the command line.
    And still some people says that Mercurial is easier to learn and better to begin with.
    None of those people can give any example why…
    This doesn’t make sense at all…

  50. @Martin: “some people says that Mercurial is easier to learn and better to begin with. None of those people can give any example why…”

    Many developers have used Subversion (SVN) as a VCS. When they try out Mercurial (Hg) they find that the Hg commands are named and act nearly identical to SVN. So the barrier of entry of switching from SVN to Hg is very, very low. Git, on the other hand, has different commands and usage patterns; forcing developers to spin up on it if they want to use Git.

  51. I was using SVN.
    I switched to Git.
    I found Git to be easier to understand than SVN was.
    Git’s branching model is easy to understand.
    Hg’s are not difficult either but there are five of them…

  52. Let’s just say that old VCS never die. We still have CVS and SVN repos internally at my job, but I also have a variety of open-source projects in Hg repos (as well as a few in Git). Since I may work on several projects on the same day, it’s a no-brainer for me to switch between SVN and Hg. I don’t have to think about anything.

    Anyway, I was illustrating why some people find Mercurial easier than Git. Both Mercurial and Git are fantastic tools. Use whatever floats your boat.

  53. @martin pettersson: “Here we have two systems that has almost identical user interfaces on the command line. And still some people says that Mercurial is easier to learn and better to begin with. None of those people can give any example why…”

    I can’t speak for everyone, but I recently evaluated both Git and Mercurial and I can’t show you why Mercurial was easier to learn because I wasn’t using the command line. Call me lazy, but I really find a lot of value in a GUI. I know some folks still like to edit their code in VI and compile from the command line, but I’m just not one of them. I get more done when I have a graphical representation of things to look at.

    So without providing step-by-step screenshots to detail every step that I took, I can’t show you why it took me a fraction of the time to get up and running with Mercurial. I can’t show you why Git kept having random issues pop up that I didn’t really understand. I can only tell you, as many others have done, that Mercurial was a lot more pleasant to use. Give me a few months working with Git, and maybe I’ll tell you I prefer Git’s way of doing things, who knows? But don’t try to act like the “Mercurial is easier” argument is invalid because I can’t show you a series of commands that you can’t replicate in Git. If the consensus among users is that the iPhone or the Mac OS or Notepad is easier to use than Android or Linux or VI, you’ve got to accept that it’s a valid argument, even if most people can’t point out a specific set of commands that are easier to do on one than the other.

  54. @James Jensen That’s incorrect. It might be easier for you, that doesn’t mean it’s easier for everyone.

    @Kiru You are the one not listening. Not even hard proof will convince of the reality, and here is hard proof:

    You see in this video how in git:

    1) visualizing and keeping track of 100 branches is no problem at all
    2) picking 10 branches of those 100, and rebasing one on top of another is straight-forward

    I did all this in under 2 minutes with core git commands. Good luck trying to do the same in mercurial.

  55. @FelipeC:
    In the introduction you were hoping your conclusions are not biased. That hope is lost. You are a simple git fanboy. Even when Kiru answered rationally and basically destroyed your arguments you kept insisting that “git is better” *lol*

    Both systems are mostly equivalent. Get used to one of those and you can solve all situations with them. Sometimes a solution in A is a bit easier, sometimes in B.
    In a position without quality arguments your obsession goes so far that you try to come up with artificial arguments, trying hard to “win” somehow.
    And your strategy to argument Mercurials named branches away is amusing. Now git doesn’t support this, so you obviously have to argument them away as useless. Omg.

  56. @Frank I have provided evidence, and I even provided a challenge. Now, without answering the challenge, all you can say about Kiru’s arguments is that they are interesting words, but not that they are true.

    Both systems are not equivalent. You can achieve more, in easier ways with Git, and I explained those use-cases. Mercurial named branches provide nothing of value, as all use-cases that can be done with named branches can be done with Git’s powerful query tools, in even easier ways, as I already explained.

  57. Nope Felipe, you are wrong, in typical use-cases it is easier to work with Mercurial. Also the named branches are of great value, and git does not have them and needs workarounds to achive something similar. Your challenges are artificial and not representative. The man-power behind git is great, but even with fewer people Mercurial comes up with more innovations. Github is very nice, but BitBucket now has a more professional crew with Atlassian.
    Your conclusion about any “winners” is not valid, as several systems still exist. Can be that other version control systems will turn out to be used even more, or that some next-generation tool will take over in 3 years.
    All in all you are mostly a fanboy and psychologically attached to git, so you try to defend your position and try to ignore why such complex projects such as Mozilla, Solaris, OpenOffice or Java chose Mercurial. Please, try to be rational about it. In the end it doesn’t matter, even with git it would be possible to manage complex projects. It is also a good tool. Currently there is no innovation, but that might change in the future.

  58. @Frank Talk is cheap, show me some evidence.

    Which “typical use-cases” are easier in Mercurial? Give me the commands, and I’ll give you similarly simple ones in Git.

    Which use-cases need named branches? Give me the commands, I’ll give you the same if not easier versions to do the same in Git. They are not workarounds.

    And yes, there’s such a thing as winners and losers. You can’t say that RCS is as successful as git, or that Bazaar is as Mercurial. And no, I didn’t ignore such big projects using Mercurial, I listed them, but they are fewer, and IMO, less important, and even diminishing in importance.

  59. Lol, you must be kiddin’. Yeah, we see how the importance of Mozilla, Java and Office is diminishing ;-)
    Sorry man, I won’t play that game of “fighting” here with shell commands in the comment section of a blog. You yourself gave an example that possibly can not be solved in Mercurial. But then you saw that it was in fact *easier* to solve with hg (8 commands vs your 9). Your other totally artificial and irrelevant task was also solved with three loc. Peace, see you on BitBucket.

  60. @Frank You can see for yourself Firefox’s demise in the stats. OpenJDK != Java. And OpenOffice is dead, it’s replaced by LibreOffice, which is maintained in git.

    Of course you would not provide the requested commands, because then your argument would be shown to be invalid.

    No. My example has not been accomplished in Mercurial, saying so demonstrates that you don’t even get what’s the point of the example. See that text where the guy said “(whatever bob committed)”, that’s where the tricky part is. The remote branches with NAMESPACES. The trick is in bob/do-test, and bob/master, the trick is in being able to see those remote branches, and distinguish them from mine, or alice’s, or even my own branches in different repositories. It is not strange for me to have branches in 5 different repositories: local, personal private work, public work, upstream, and public github, and that’s just mine, now imagine adding a few contributors. That’s why I chose a new example with 10 repositories with multiple branches, and why I requested a video, because then the commands would need to be real, and “(whatever bob committed)” would have to be replaced with something, and that something is what is not easily available in Mercurial.

    Get it?

  61. So basically…git is for geniuses and mercurial is for mortals. I know which category I belong to anyways. Git tends to give me painful headaches. I have to pay more attention to what I am doing in Git than to the code I am building.

  62. I don’t mean to interrupt the flamewar, but in your example couldn’t you use the interactive (-i) flag when you rebase tmp-do-test onto master, and remove the bad commit from the list before the rebase even starts? Otherwise, if there’s no conflicts with Bob’s “bad commit”, it’ll get included with your rebase automatically, and the mergetool won’t help you at all.

  63. +Mike Yes, you could do that, if you already know that would be the problem, but sometimes you don’t know, which is why I decided to pick this example. Mergetool only helps to realize, this is a commit you don’t really want… you can just quit, and then skip that commit.

  64. Obviously biased toward Git, refuting Google arguments. History is Sacred is not a judgment value, that’s a design feature.
    I use neither mercurial nor Git but tend to think Mercurial is stronger and Git better defended because more in view and coming from influential people, which means nothing nut politics.
    So I vote for Mercurial.

  65. +UsingNeither Wrong. One project can choose not to allow changing history, it’s perfectly fine. But even in mercurial, there are extensions to allow reorganizing the history. If everything else fails, there’s quilt. So, the developer can always do whatever (s)he wants.

  66. +Teancum

    Of course not, that guy doesn’t know what he is talking about. His use-cases are perfectly supported by Git:

    A) I need to know which branch ab3e2afd was committed to know whether to include it in the change control review for the upcoming release

    % git log master..release

    It will list all the commits in the ‘release’ branch that are not in the ‘master’ branch.

    B) I need to know which change is the first change in the release branch because I’d like to start a new topic branch with that as my starting point so that I’ll be as current as possible and still know that I can do a clean merge into master and release later

    % git merge-base master release

    Will find the first common commit of both master and release

    C) I need to know where topic branch started so that I can gather all the patches up together and send them to a colleague for review.

    % git send-email --to john release..topic

    It will send the patches in the topic branch that are not in release.

  67. Weird, a branch with no history? That isn’t a branch, that’s just a working copy. And if it takes 10 commands to make a working copy, that is definitely not user friendly.

  68. I know you think git branches are the bees’ knees. I read your little flame up there.

    First of all, git branching is a subset of hg branching since 1.8. It’s technically been a subset since 1.6, except that it had to be turned on before. It’s in core and always on since 1.8

    Hg has bookmarks, anonymous branches, and named branches. Of these, git only has bookmarks.

    git is indeed very featureful in other aspects. I don’t think there is anything that one DVCS can do that the other can’t do. Fine, challenge me with CAN YOUR VCS DO THIS, if you want, and I’ll show you how to use it. I’m not sure you’ve actually tried using hg for any length of time.

    I’ve tried using both. I’ve been using git for about six months. I’ve been using hg for a longer time. I’ve also tried darcs and bzr. Of the whole bunch, git is by far the most complex, because it is, by its own admission, the most stupid. That means you have the most to learn in order to use it. None of the other DVCSes I’ve tried require you to know the implementation details of how they work of how they use. Yes, blobs, trees, hashes, refs, detached HEADs, tracking branches, reflogs; these are all implementation details, and git sticks its ugly guts out from the moment you start using it. It’s not true that you can stick to a subset of git usage and be safe. You will eventually come upon a problem that requires knowing git’s guts. Look at yourself up there blogging about how proud you are to know about git’s guts.

    It’s true that once you get over the initial bootstrapping of learning the ugly guts of git you can use it effectively. And it is indeed powerful. It’s also horribly lacking in encapsulation, but its users love learning about this lack of encapsulation, so I don’t see this ever getting any better.

  69. +Jordi Gutiérrez Hermoso

    You obviously didn’t read many of the comments, as I’ve explained again and again what git can do that mercurial can’t. And no, git branching is not a subset of hg branching, I already explained that in the post.

    The problem is namespaces; mercurial doesn’t have them. I made a challenge to Kiru, and he didn’t take it, you, or any mercurial fan can try it, but I’m sure they’ll give up, because they’ll recognize that it is indeed pretty difficult and tedious to do the same in mercurial. Feel free to prove me wrong.

  70. My 2c is this. I’m in the gaming industry and advocated using Git. Personally, I like Git and would still be fighting for our company to use it if it weren’t for one major issue… It doesn’t handle large amounts of data very well. For our smaller projects it’s great, but with one of our projects, it’s not that Git isn’t worth using, it just doesn’t work. It chokes when pulling a fresh copy of the repository onto one of our machines. When pushing large amounts of data it often dies at the very end of the push (it disconnects for some reason) and we’d have to push again which takes forever. It would then disconnect again and we’d have to try again and again and again. We ended up going back to SVN for that project. I’m now looking into Mercurial and doing some tests and so far it looks promising. This isn’t me bashing Git, I like Git a lot. When you’re using it on a project that’s smaller in size (say less than a GB or two) it’s super fast and you can do a lot of neat tricks with it. I use it in conjunction with Dropbox to get my repos from Home to Work and vice versa. But, if you’re trying to use it on projects that are going to be several GB in size and have your team members uploading large amounts of data to a remote server, I would advise against using Git. It’s not that it doesn’t work well with these projects… it doesn’t work at all on these projects.

  71. Nathan, I have seen this problem on 32 bit windows machines only. I guess it is hitting the 3GB ceiling.
    Have you seen this on Linux machines as well? 32 or 64 bit?
    Martin

  72. I’d like to add my 2c. I like both tools and used Mercurial for about 2 years. But I have to admit – Git has features that I really miss in Mercurial. Specifically,

    1. Local branches and squash merging. For example, I have a colleague programmer. He worked on a new feature for about a month. He made a lot of commits and merges that I really don’t care about. I just want to merge his result as a single commit. In Git I’d just fetch his changes, use squash merge and strip his branch. On Mercurial I cannot do such a simple thing. After a merge, i cannot strip off commits I don’t need.
    Kira proposed to use mq to acomplish this but it doesn’t work. Mercurial’s patch (qpush/qfinish) does not handle merge conflicts. And it is understandable, because patches have no history and therefore 3-way merge cannot be used. I have to apply rejected hunks myself and it is very annoying.
    I also like in Git that all local branches must me named and and can be purged. If I have 5 anonymous heads i can eventually forget the reasons for each of them. After a merge it becomes even more messy, since heads of two branches are in the same commit. You may suggest me to use bookmarks and I do, but then I have to pay attention to the fact that namespace to bookmarks is global. So Mercurial have a lot of work to do before bookmarks will useful as local branches.

    2. Git has a superior storage model over Mercurial and I am confidant with that. Here is a use case. I like to track changes to SLURM, the open source cluster resources management system. I used hg-git extension to clone the repository from GitHub. After clone successfully completed I notice that it takes about 500 MB and zillion of files in Hg repo. In contrast, git repository is about 80 MB and dozens of files. I found out why it is so. Mercurial tracks history in per-file basis. But if you have a lot of renames especially directory renames, Mercurial will duplicate its storage files and never delete them as it has a history. So renames multiply files that are kept in repository. In the particular case, SLURM was imported from Subversion and had a lot of tag-directories that later was deleted. Mercurial cannot compact content acros files and cannot delete these obsolete files and directories, so we end up having a huge repository with a lot of small files.
    So in Mercurial you better not rename files a lot or your repo will grow linearly.

  73. Mercurial comes up with more innovations. Github is very nice, but BitBucket now has a more professional crew with Atlassian.

    BitBucket now supports Git too. Smart move.

  74. @FelipeC: Do you see that you just managed to break the repositories for 10 people with your rebases as soon as they pull (or at least made their local branches obsolete)?

    In Mercurial you would not rebase the branches, but merge them. Then when they pull, they get a version with their branch merged. Rebasing is used mostly for local branches, you don’t want to publish, yet.

    The workflow on the Mercurial side thus looks a bit different:

    (1) hg paths # see all related repositories, set in .hg/hgrc, section [paths]
    (2) hg incoming # see the changes
    (3) hg pull # get them
    (4) hg merge # integrate them
    (5) hg commit # store the integration
    (6) # back to (2)

    Incidentally that’s what pull requests in github do (incoming till you’re ready to pull), just to take this to your home turf :)

    Sadly many git users judge the power of Mercurial by comparing its core commands with all the commands of git. They take a fraction of the time they used for learning git and assume that they now know all of hg. But what they know are the safe core usecases which don’t destroy history.

    Mercurial developers emphasize using these instead of extensions (where possible), because they are what new users need. Naturally you don’t see the same power when you ignore 50% of functionality.

  75. +Arne No, nothing is broken; all they have to do is rebase again, problem solved.

    Sure, you can just merge just as well in git, but that’s a red herring. The point is that for this particular case, git beats hg.

    It’s easy to dismiss features of git that work poorly on hg, but by doing that you are admitting that git works better. Period.

    And no, I know better what I need, not hg developers.

  76. If you really want to rebase:

    for path in $(hg paths | cut -d = -f 1 | xargs); do
    hg pull
    done

    hg heads –template “{node|short} {author|person} {bookmarks}\n” # see the heads with bookmark information.

    # for each head you want:
    hg rebase -b -d tip
    # in case of an error, use your automatically opened merge tool, then:
    hg resolve -m
    hg rebase -c
    # done

    Could you provide your test repos? I don’t want to create my own. The test should be equivalent, after all.

    PS: The rebase extension is shipped with mercurial, so I consider it part of Mercurial.

  77. PS: And they have to rebase again, as does everyone who pulled from them in the meantime, and everyone who…

    PPS: Adding {desc|fill68|firstline} to the heads template, gives you the fist 68 characters of the commit message – which could come in handy.

  78. Arne,

    hg rebase is notorious for being buggy and unstable. I myself encountered several extremely weird behavior including repo corruption.
    I think this is the primary reason ‘rebase’ is not yet included to the core Mercurial commands and remains as an extension that you can use on your own risk.

    See https://developer.mozilla.org/en/Mercurial_FAQ

  79. +Arne Here’s the trick: ‘for each head you want’. In mercurial you would always have trouble finding that information, while in git it’s very easy: alan/feature_x, or pc/test_y, github/wip_z, etc.

    So, again; namespaces.

  80. @FelipeC: You mean, *mandatory* namespaces, right? You can do the same with bookmarks, but you don’t have to. The main difference I see is that your local git decides on the namespace while with bookmarks, the developers would decide on the namespace.

    To paraphrase you: And no, I know better what I need, not git developers.

    But yes, it might be interesting to add an option to bookmarks to add a namespace to foreign bookmarks when pulling them.

    Though: Did you see that in my example the displayed changesets have the committer information? The output of the heads command with the ad-hoc template looks like this:

    $ hg heads –template “{node|short} {bookmarks} – {author|person}: {desc|fill68|firstline}\n”
    db8b0ee74025 – Hao Lian: largefiles: ensure destination directory exists before findfile
    6565fe84c47c – Arne Babenhauserheide: update: without revision update to master or /master

    (I slightly reworked the template to make the output nicer)

    As alternate version, you could get the log of the commits introduced in each head:

    $ for head in $(hg log -r “heads(all()) – .” –template {node}\ ); do echo $head; hg log -r “ancestors(${head}) – ancestors(tip)” –template “{node|short} {bookmarks} – {author|person}: {desc|fill68|firstline}\n”; echo ; done
    6565fe84c47cb23186edd75dd255f32b59a701e6
    0cc7332a0bb2 – Arne Babenhauserheide: clone: get all bookmarks before updating
    8f614fd777b7 – Arne Babenhauserheide: clone to master bookmark if available.
    b5307f7085af – Arne Babenhauserheide: clone to master, even if it is not on the default branch.
    6565fe84c47c – Arne Babenhauserheide: update: without revision update to master or /master

    (see hg help templating and hg help revsets for details)

  81. If I had used bookmarks, the list of heads would have looked like this:

    $ hg heads –template “{node|short} {bookmarks} – {author|person}: {desc|fill68|firstline}\n”
    db8b0ee74025 largefiles – Hao Lian: largefiles: ensure destination directory exists before findfile
    6565fe84c47c master_bookmark – Arne Babenhauserheide: update: without revision update to master or /master

  82. Instead of hg heads you might want to use a revset for log:

    hg log -r “heads(all()) – .” –template “{node|short} {bookmarks} – {author|person}: {desc|fill68|firstline}\n”

    This shows all heads but the head of my working directory → all heads I might want to merge/rebase.

    $ hg log -r “heads(all()) – .” –template “{node|short} {bookmarks} – {author|person}: {desc|fill68|firstline}\n”
    6565fe84c47c – Arne Babenhauserheide: update: without revision update to master or /master

  83. PS (again): I never was in the position to have to integrate changes from a hundred branches (no projects of that size), so all these solutions are ad-hoc, using just my general understanding of Mercurial and some calls to `hg help` for details.

  84. @Ruslan: Thanks! I just asked at the mercurial list about that. I hope it will get fixed fast (might have been overlooked in the largefiles flurry before the freeze: support for large binary files; shipped with hg since 2.0).

  85. +Arne

    You mean, *mandatory* namespaces, right? You can do the same with bookmarks, but you don’t have to. The main difference I see is that your local git decides on the namespace while with bookmarks, the developers would decide on the namespace.

    To paraphrase you: And no, I know better what I need, not git developers.

    That’s braindead. Like saying; I know better than git developers, I don’t need branch names.

    What about me? (And the rest of sane people). I want namespaces to be always there. And no, mercurial bookmarks don’t solve that issue, for example if two repositories have the same branch, e.g.: ‘bob/test’, and ‘alice/test’.

    And yes, I saw that in your examples you have the committer information, but that’s not enough. Sometimes all the remote repositories are mine, but each one for different purpose.

    You already admitted it, true namespaces would be nice.

  86. @Felipe: Well, I know my needs better than git developers: I don’t need branch names for all my repos. I have anonymous branching with Mercurial. If my repo gets bigger, I start branching.

    That you assume that only people who want namespaces are sane seems rather arrogant to me… There’s always the possibility of developers actually interacting. After all, changing a bookmark name is a trivial operation.

    Repo-namespaces would just mean, combining incoming with heads.

    Since you claim that hg can’t do that, I decided to demonstrate to you how to do what you want: creating a hg repo with namespaced bookmarks.

    The result is here, for replicability it also creates all test repos.
    https://bitbucket.org/ArneBab/hg-test-namespaced-bookmarks

    Run it with python test.py. Then cd into mine and use

    $ hg bookmarks

    it gives you the list of namespaced bookmarks

    For rebasing just use

    $ hg rebase -d [name of the bookmark]

    Besides: How exactly do you create the branches.txt file? In the video you don’t show that.

    … besides: pull with namespaced bookmarks should be really easy. I could do it in a shell script. Internally it should be far easier, so you can simply specify

    hg pull -B –bookmark-prefix [prefix]

  87. +Arne

    Well, I know my needs better than git developers: I don’t need branch names for all my repos.

    People often don’t know what they are missing.

    That you assume that only people who want namespaces are sane seems rather arrogant to me.

    The sane people would understand that even if they don’t want namespaces, other people might. You are are the one being arrogant in saying that if you don’t need it, nobody else does.

    creating a hg repo with namespaced bookmarks.

    You know very well that’s not the same. The namespaces should be created automatically while defining a repo, and the remote branches should be fetched, and updated when the repo is updated. Your approach is just a hack that wouldn’t scale and would have trouble with updates in the branches.

    Just admit it, namespaces wouldn’t hurt you, and would benefit other people.

  88. Namespaces would hurt me for my small projects: needless overhead. They make branching more complex. In Mercurial you just use `hg update [bookmark]` to switch to a bookmark. And `hg rebase -b [rev]` instead of `git rebase HEAD master `.

    And the “hack” would actually be a 10 lines patch to Mercurial. And updating is no problem, because I can pull and remove bookmarks at will without affecting the history.

    Git needs namespaces because every head has to be referenced by a branch. Mercurial bookmarks do not have this architectural limittion.

    But let’s recap: yöu told me that it’s bad that Mercurial enforces a programming style. Then I showed you that bookmarks can do the same as branches, and more. Now you tell me, that it is good that git restricts my coding style.

  89. +Arne

    Namespaces would hurt me for my small projects: needless overhead.

    No, they won’t. Suppose you have these git refs:

    refs/heads/master
    refs/heads/feature_x
    refs/remotes/bob/master
    refs/remotes/bob/test
    refs/remotes/alice/master
    refs/remotes/alice/test

    Your branches are ‘master’ and ‘feature_x’, they have no namespace, there’s no overhead. You don’t ever need to see the remote branches, so no need to see the namespaces.

    If you want to track some of these branches, you can create tracking branches:
    git checkout -b test1 bob/test
    git checkout -b test2 alice/test

    Now you have two local branches ‘test1′, and ‘test2′, with no namespaces.

    And `hg rebase -b [rev]` instead of `git rebase HEAD master `.

    That git command is wrong. If what you want is to rebase into master, you do ‘git rebase master’. Simple.

    And the “hack” would actually be a 10 lines patch to Mercurial.

    Once it’s released into mercurial, we’ll talk.

    And updating is no problem, because I can pull and remove bookmarks at will without affecting the history.

    Wrong. When you pull ‘alice/test’ a local bookmark ‘test’ will be created, so you have to manually update ‘alice/test’, and when you want to do the same for ‘bob/test’ there will be conflicts, unless you remove the local one. That would be massively painful, specially if you already have your own ‘test’ bookmark.

    Clearly an ugly hack.

    Git needs namespaces because every head has to be referenced by a branch.

    Wrong again. Branches are only one kind of ref, one can create custom refs that would be ignored by git tools.

    For example, we could create a “bookmark” ref:

    git update-ref refs/bookmarks/test test

    If you run ‘git branch’ (or any command that deals with branches), that ref will be ignored, because it’s not a branch, but the commits will not disappear, because there’s a ref pointing to it.

    But let’s recap: yöu told me that it’s bad that Mercurial enforces a programming style. Then I showed you that bookmarks can do the same as branches, and more.

    And wrong again. Bookmarks cannot do the same as git branches; here’s one thing they cannot do:

    git checkout -b tmp alice/test
    git push github tmp:fixes_for_alice

    To do the same in hg you would have to create transitionary branches. IOW; hacks.

    Now you tell me, that it is good that git restricts my coding style.

    That’s a lie. Nobody in this blog post has been able to show a single instance where git restricts you in any way. Anything that you can do with Mercurial, you can do with Git. Period.

  90. re rebase: The rebase command is taken from your video… why did you use that?

    re overhead: `git checkout -b test1 bob/test` ← this is overhead. Why do I have to create a local branch just to track a branch?

    re pull bookmarks: you’re wrong: I can pull without getting bookmarks and then do the prefixed bookmark-pull.

    re push fixes for alice: what is fixes_for_alice? A branch head? I can get a bookmark from a remote repository and rename it, as I showed you. If you mean pushing everything from alice/test till fixes_for_alice: hg push -r alice/test::fixes_for_alice. Normally a simple hg push -r fixes_for_alice should suffice: It pushes all commits which are ancestors of fixes_for_alice.

    re git bookmarks: you still have to reference that. What do you do if someone else uses the same reference? Can you use it? Can your commit then suddenly disappear? Or do you need a namespace? → more general: A git commit has to be referenced by a ref. So shared refs need namespaces to avoid losing commits.

    re git can do anything: aside of the overhead:

    * hg up -r -2; hg commit -m “anonymous head”; hg merge; hg commit -m “merged into the anonymous head for a quick fix at the right place in history without disrupting published history”
    * record the branch name persistently in the commit to track for which feature something was implemented without filling up the commit messages.
    * hg site user:password@ftp.dom.tld/path/to/repo; hg clone dom.tld/path/to/repo ¹
    * hg clone git://dom.tld/repo.git; hg -R repo push ssh://dom.tld/repo.hg
    * track hg, git and subversion subrepos directly in a hg repo
    * hg b add “show FelipeC some more cool hg tricks” # integrated bugtracker as hg command
    * hg fn-create USK@/freenet-repo ; hg fn-reinsert # upload a Mercurial repo to freenet for anonymous and censorship resistant code sharing and reinsert everything but the top-key without needing the master key by using the infocalypse extension. All integrated in Mercurial commands offering the builtin help, consistent options and such.
    * hg log -r “ancestors(rev1) – ancestors(rev2)” # revsets: all ancestors of rev1 which are not ancestors of rev2.
    * write an extension which uses the hg functions directly – and can check which extensions are active.
    * …

    On the raw history side, git and mercurial are equivalent, as you can see by the ability of Mercurial to act as transparent bridge to a git repo without losing information (hg-git).

    ¹: Upload to FTP. But OK, that’s unfair: It’s an extension I wrote myself.

  91. +Arne

    rebase: The rebase command is taken from your video… why did you use that?

    The command I used in the video is different “git rebase –onto HEAD master comnittish” (note the –onto). First, I used ‘comnittish’ because I didn’t want to switch to that commit beforehand–if you already are in the branch you want to rebase, that’s not needed. I specified ‘–onto HEAD’ because I wanted to rebase into the current commit without having to create a temporary branch, and ‘master’ because I knew that was the origin of all the commits. I could have removed ‘–onto HEAD master’ and just use HEAD. Sometimes it’s even possible to don’t mention the branch.

    overhead: `git checkout -b test1 bob/test` ← this is overhead. Why do I have to create a local branch just to track a branch?

    You don’t. But you are complaining about the ‘bob/’ namespace overhead. Normally you don’t even need to type the whole thing, so it’s not a problem to have those extra characters, but since you are being unreasonable, you can type that single command, one single time, and you would get the suboptimal hg bookmark behavior.

    pull bookmarks: you’re wrong: I can pull without getting bookmarks and then do the prefixed bookmark-pull.

    Prove it. There’s no way to get alice’s ‘test’ bookmark unless you pull it, and when you do, you’ll have a ‘test’ bookmark in your local repository. Show the commands.

    push fixes for alice: what is fixes_for_alice? A branch head? I can get a bookmark from a remote repository and rename it, as I showed you. If you mean pushing everything from alice/test till fixes_for_alice: hg push -r alice/test::fixes_for_alice. Normally a simple hg push -r fixes_for_alice should suffice: It pushes all commits which are ancestors of fixes_for_alice.

    You clearly need to do a bit of homework to understand git branches–git push github tmp:fixes_for_alice has nothing to do with hg push -r alice/test::fixes_for_alice. This command will take a branch named ‘tmp’ (which was based on ‘alice/test’ but presumably has a few fixes on top now), and push it to the ‘github’ repository with the name ‘fixes_for_alice’.

    It would be quite tedious to do the same in mercurial. I guess something like:
    hg bookmark tmp -r alice/test
    hg bookmark -m tmp fixes_for_alice
    hg push -B fixes_for_alice
    hg bookmark -m fixes_for_alice tmp

    And if you already have a branch named ‘fixes_for_alice’, you have to add two extra commands:

    hg bookmark -m fixes_for_alice old_fixes_for_alice
    hg bookmark -m old_fixes_for_alice fixes_for_alice

    So, as I said, hacks. This happens because mercurial assumes that bookmarks are global. In git, they are local, and remote ones are properly namespaced, so it’s easy to identify them, and it’s easy to push them with different names to different repositories to avoid collisions, and make them even more easy to understand.

    git bookmarks: you still have to reference that. What do you do if someone else uses the same reference? Can you use it? Can your commit then suddenly disappear? Or do you need a namespace? → more general: A git commit has to be referenced by a ref. So shared refs need namespaces to avoid losing commits.

    You are thinking in mercurial terms. In git, refs are local nobody can change your local refs, in fact, a ref such as ‘refs/bookmarks/test’ will never be pushed, or pulled (unless you do some dark magic… maybe). So no, it cannot disappear, you can use it, and you don’t need a namespace.

    git can do anything: aside of the overhead

    There is no overhead. Having a few extra characters for the repo prefix is nothing compared with the amount of hacks you would need to achieve the same in mercurial. Just look at your hacky script, do you think that would be accepted as a mercurial extension? Quite a lot more code would be needed to actually be usable, and then, you would end up with the same thing as git.

    hg log -r “ancestors(rev1) – ancestors(rev2)” # revsets: all ancestors of rev1 which are not ancestors of rev2.

    git log rev2^..rev1^

    hg clone git://dom.tld/repo.git; hg -R repo push ssh://dom.tld/repo.hg

    I don’t see what’s special about that.

    record the branch name persistently in the commit to track for which feature something was implemented without filling up the commit messages.

    As I already explained, this can be found out very easily with git commands.

    hg up -r -2; hg commit -m “anonymous head”; hg merge; hg commit -m “merged into the anonymous head for a quick fix at the right place in history without disrupting published history”

    git checkout HEAD~2; git commit -m "anonymous head"; git merge master; git commit -m "meh"

    hg b add “show FelipeC some more cool hg tricks”

    This must be a joke. This can be done with a script, name it git-b, put it into your PATH, and you can do the same ‘git b add’ command. This has nothing to do with SCM.

  92. re prove it: see the code I already showed you. It gets the bookmarked revision without pulling it and assigns a different name.

    re meh: can you also push in between? to a tensing repo, for exmple?

    re git commands: does git help b work then? Or do I have to recreate the machinery myself? And you are the one who claims that git can do stuff hg can’t, though the difference for your cases is simply that (a) you don’t know hg well enough and (b) hg has a different UI. And if a script suffices, then my “hack” is a fully qualyified way of working.

    re 1..2: does that give you the difference between all ancestors?

    re a lot more code for the hack-integration: no, internally done it would need much less code.

    re push tmp:foo: if you count that as big difference: I just showed you that I can pull bookmarks under different names. That’s no huge difference, but just a matter of “noone saw eough value in it yet to do it”. The whole bookmarks pushing logic needs just 19 LOC, and is just pushing keys to a remote dict. Adding a renaming option would be trivial → http://selenic.com/hg/file/f3b5ba25d217/mercurial/commands.py#l4311

    But I don’t need pushing under different name, so that “one command for binding” is just overhead for me.

    Though, if you need it:
    hg boo fixes_for_alice -r alice/test
    hg push -B fixes_for_alice
    hg boo -d fixes_for_alice

    If I already hve a bookmark named fixes_for_alice, I likely won’t need that anymore (else I’d have used a better name): just add -f (force) to replace it.

    While I m used to hg, you are bound to git thinking, where branch renaming is an actual history operation, wheras in hg renaming a bookmark simply means changing a marker on existing history.

    But yes, I still would need more learning to be able to use git efficiently. But that’s a point other people in this thread already made…

  93. PS: re git bookmarks: then you have overhead in git to achieve what you have natively in hg. So face it: git and hg are equal. They differ in design philosophy which is why the main usecases for the design are simple and the other cases have some overhead. What you actually claim is not that git is more powerful, but that the focus of the git UI is the right one for you. And what will you do if hg bookmarks grow an optional equivalent to namespaces? Will you then agree, that this difference actually is quite small (seen on the hg side)?

  94. One more note: The main work in the script is simply setting up the testing repos. Getting the bookmark renaming to work on the shell (to show that it needs no extension) just took some sed and cut magic.

    Since you kept insisting that it must be harder to do this internally, I now turned the script into an extension. The relevant code is just 9 lines of code: https://bitbucket.org/ArneBab/hg-test-namespaced-bookmarks/src/be7cbb8ac2cc/test.py#cl-53

  95. @Ruslan: It was not me who did the fix :) You should thank Stephano. He stepped up and fixed the issue.

    Besides: The reason that rebase is not in the core commands is that it rewrites history and disturbs the workflow of all other contributors (and you on your next pull) when it changes already propagated changes. The central rule is: core commands preserve your work and lead to a non-invasive workflow.

  96. Thank you, Stephano, you save me a lot of pain!
    @Arne, Thank you for clarification! That makes a perfect sense to me.

  97. prove it: see the code I already showed you. It gets the bookmarked revision without pulling it and assigns a different name.

    You mean this?

    % hg incoming 'alice' -Bfq | tee _tmp/alice
    feature10 db52788d3232
    feature12 dbbbf6f52ec9
    feature14 63de77bfc564
    feature17 6cd1fcb2131b
    feature19 a895ec5397f8
    feature21 d6518ea83ddc
    feature23 cd0260354a45
    feature4 4a77fd12d801
    feature6 758e4beace9b
    feature9 7236611b9fbb

    And then, supposing j contains ” feature10 db52788d3232″:

    % echo $(echo $j | sed s/-/\ /g | xargs) | cut -d " " -f 1
    feature10

    % echo $(echo $j | sed s/-/\ /g | xargs) | cut -d " " -f 2
    db52788d3232

    And then:
    % hg bookmark alice/feature10 -r db52788d3232

    Wow. That was easy! And I have to do that everytime I want to update a branch? Again, clearly a HACK.

    And BTW, no need for this horrible mess; echo $(echo $j | sed s/-/\ /g | xargs) | cut -d " " -f 1, echo $l | awk '{print $1}' does the trick.

    meh: can you also push in between? to a tensing repo, for exmple?

    I don’t know what you mean by ‘tensing repo’, but yes: git push origin HEAD:refs/heads/foobar.

    git commands: does git help b work then?

    Yes, if the ‘git-b’ manpage exists.

    And you are the one who claims that git can do stuff hg can’t, though the difference for your cases is simply that (a) you don’t know hg well enough and (b) hg has a different UI. And if a script suffices, then my “hack” is a fully qualyified way of working.

    Wrong. As I already explained, bug tracking has absolutely nothing to do with SCM, if for some reason mercurial was able to turn on my microwave, and git wasn’t, that’s a red herring, it’s completely irrelevant to the discussion, we are talking about SCM, so stop with the distractions.

    And no, a hack doesn’t fully qualify, it has to be available to everyone, it has to be part of the core, or at least an extension. Otherwise, I could say the same about git: I can create scripts that add “bookmark” functionality, by crippling the namespaces and always copying around remote branches locally.

    does that give you the difference between all ancestors?

    No, it gives you the commits that are ancestors of 2, but not ancestors of 1. IOW; exactly what you wanted.

    See gitrevisions(7).

    a lot more code for the hack-integration: no, internally done it would need much less code.

    Prove it. Once you try to push it as an extension, it would be easy to find bugs, and missing features; the code would increase dramatically.

    Almost always real code is more code than proof of concept implementations.

    push tmp:foo: if you count that as big difference: I just showed you that I can pull bookmarks under different names.

    Yes, but how about alice? She needs to have an ‘arne/test’ or ‘arne/fixes_for_alice’ bookmark in order to don’t mess with her own bookmarks. Therefore, this code needs to be an extension, not just a hacky script in your machine.

    But I don’t need pushing under different name, so that “one command for binding” is just overhead for me.

    You can’t say “mercurial does everything”, and then say “oh, it doesn’t do that, but I don’t need it. It doesn’t matter if you need it or not, the point is that git does it, mercurial doesn’t, and people rely on it.

    Though, if you need it:
    hg boo fixes_for_alice -r alice/test
    hg push -B fixes_for_alice
    hg boo -d fixes_for_alice

    A hack.

    If I already hve a bookmark named fixes_for_alice, I likely won’t need that anymore (else I’d have used a better name): just add -f (force) to replace it.

    Clearly, ‘fixes_for_alice’ was just an example, it could be ‘tmp’, or whatever. Avoid red herrings.

    While I m used to hg, you are bound to git thinking, where branch renaming is an actual history operation, wheras in hg renaming a bookmark simply means changing a marker on existing history.

    Are you serious? In git branches are mere pointers, renaming them is not recorded in history. Are you sure you know how git branches work at all?

    But yes, I still would need more learning to be able to use git efficiently. But that’s a point other people in this thread already made…

    No, you don’t. You have local, and remote branches, and they can have different names, they are just pointers to commits. That’s it, simple, but somehow you are claiming that’s bad without being able to substantiate your claim, and at the same time say it’s possible to do the same in mercurial without hacks, but so far you have only shown complicated hacks to do the same.

  98. @FelipeC: The “hack” is not a hack. It just takes three commands to do the work. When git requires binding a local branch, it requires two commands from everyone. Mercurial requires three commands from the people who want the feature. Mercurial allows pushing under a different name. It just requires more steps.

    re git branches: Git branches hold the heads. Mercurial bookmarks don’t. They are mere pointers with a single purpose: making it easy to address an arbitrary revision. In Mercurial a head without a marker does not get garbage collected.

    What I say is that I don’t like having to bind a remote branch to a local branch. That’s overhead, because I don’t need it.

    And yes, the awk solution is nicer than my sed+cut wrangling.

    re alice also needs this: Why? Maybe she does not need to manage a hundred remote repositories. She could prefer to just merge fixes_for_alice whenever someone pushes them.

  99. +Arne

    Mercurial allows pushing under a different name. It just requires more steps.

    No, it’s a hack, you are just rationalizing it. If it’s not a hack, then how a hack to push branches with different name look like? And if this is allowing that feature, how would disallowing that feature look like?

    When git requires binding a local branch, it requires two commands from everyone.

    No, git doesn’t require that, you are the one being unreasonable and wanting that. It’s not two commands from everyone, just one, just from you.

    git branches: Git branches hold the heads. Mercurial bookmarks don’t. They are mere pointers with a single purpose: making it easy to address an arbitrary revision. In Mercurial a head without a marker does not get garbage collected.

    There is no difference. Unlike what you said; git branches are mere markers on existing history, and renaming them is not an actual history operation, just like hg bookmarks.

    What I say is that I don’t like having to bind a remote branch to a local branch. That’s overhead, because I don’t need it.

    Then don’t do it, use the remote branch directly, like the rest of the world: alice/test.

    alice also needs this: Why? Maybe she does not need to manage a hundred remote repositories. She could prefer to just merge fixes_for_alice whenever someone pushes them.

    Because if everyone has the same ‘feature_x’ bookmark, but I used your script, got ‘alice/feature_x’, and then created a local ‘feature_x’ and made some modifications to do something different, when alice pulls from my repo, her ‘feature_x’ will be replaced. IOW; I would have to remove the repo prefix in my head in order to make sure my bookmarks don’t conflict with the others, or the other people fetching from my repo would need this script to properly set the prefix.

    Anyway, you didn’t answer my comment regarding your hack. If you can create a script to simulate git’s branch behavior with namespaces, then I can create a script to simulate mercurial’s behavior with bookmarks.

    In fact, I already did it, because that’s precisely what I do with my backup repository:

    http://article.gmane.org/gmane.comp.version-control.git/184990

    I could add an option to sync the other way around, and it would be exactly the same, and it would be in git’s core, not a random script hidden somewhere in the web.

  100. @FelipeC: So a git user does not have to bind the branch? And if I work on alice/test and push, that gets transformed into what? And if so, where exactly is your advantage? Then this is *the same* as Mercurial bookmarks, with the sole exception of offering a local renaming scheme and putting a namespace in. Which means that you aren’t really talking about branches, but about git-remote. Which is the equivalent to hg paths; with more convenience features.

    (took me far too long to realize this. Could be, because you left it out of your initial post. Or am I wrong in assuming that having a bob/do-test means that you added bob as remote before you did the example?)

    So what I can agree to is that git remote seems quite useful for maintainers, and that it would nice if hg paths would include some ideas from git remote.

    And a *hack* to push branches with different names would look like this:

    hg up -r “p1(roots(branch()))”
    hg branch [new name]
    hg commit -m “new branch root”
    hg rebase –keep –detach -b
    hg push -b [new name]
    hg strip “roots(branch(new name))”

    That has qualities of a dirty hack: non maintainable, a huge hassle to all others and especially me, …
    Using named branches like this would even be against their explicit design.

    The bookmarks solution on the other hand works with the features bookmarks provide.

    But I now learned one thing: FelipeC ⊂ git-core-devels. No wonder you perceive git as easy and take “100 remote branches” as usecase…

    re other people pulling bookmarks: that could happen, but it would just be a minor inconvenience, since the revision with that bookmark is still there and part of the history graph = easy to find. And if it’s a head, it will still be shown as head.

    As final note, there’s one thing I want to point out: I took your rebasing challenge. And I finished it without previous experience in managing very many remote repositories. You had some complaints about the way I did it, but I took the challenge and it worked in the same way as in git.

    And you still did not explain to me where that branches.txt came from…

    PS: And git gc –auto does not do a very good job of keeping repository sizes stable: http://draketo.de/proj/hg-vs-git-server/test-results.html#results

  101. +Arne

    So a git user does not have to bind the branch? And if I work on alice/test and push, that gets transformed into what?

    ‘alice/test’ is a remote branch, you don’t work on that, if you check that out, you get a detached HEAD (anonymous head), if you push that somewhere, you have to specify the name of the branch (git push github HEAD:refs/heads/fixes_for_alice).

    And if so, where exactly is your advantage?

    The advantage is that it’s namespaced so ‘alice/test’ doesn’t conflict with ‘bob/test’, or the local ‘test’ branch.

    Then this is *the same* as Mercurial bookmarks, with the sole exception of offering a local renaming scheme and putting a namespace in.

    Duh! How many times have I mentioned namespace now?

    Which means that you aren’t really talking about branches, but about git-remote. Which is the equivalent to hg paths; with more convenience features.

    (took me far too long to realize this. Could be, because you left it out of your initial post. Or am I wrong in assuming that having a bob/do-test means that you added bob as remote before you did the example?)

    I was talking about remote branches, so of course you have to add a remote to see them. This is a very basic concept. Have you even seen the official git tutorial?

    http://schacon.github.com/git/gittutorial.html

    So what I can agree to is that git remote seems quite useful for maintainers, and that it would nice if hg paths would include some ideas from git remote.

    Thank you. That’s what I was saying.

    That has qualities of a dirty hack

    But we are not talking about dirty hacks, just hacks ( It is somewhat similar in spirit to a workaround, only without the grace).

    But I now learned one thing: FelipeC ⊂ git-core-devels. No wonder you perceive git as easy and take “100 remote branches” as usecase…

    What is “git-core-devels”? I have sent patches to git, but so have thousands of people. In fact, in my git development I usually have only one remote, and not that many branches. It’s in my other projects that I use many more remotes and branches, so my contributions to git are irrelevant.

    As final note, there’s one thing I want to point out: I took your rebasing challenge. And I finished it without previous experience in managing very many remote repositories. You had some complaints about the way I did it, but I took the challenge and it worked in the same way as in git.

    No, you haven’t. For this challenge you need to do the same I did, and push a video of it somewhere, using hg commands. If you want help from your script, you must copy paste the commands manually, or make a mercurial extension, and push it to mercurial maintainers.

    And in case it’s not clear (even though I already mentioned it), the video must show that:

    1) visualizing and keeping track of 100 branches is no problem at all
    2) picking 10 branches of those 100, and rebasing one on top of another is straight-forward

    And you still did not explain to me where that branches.txt came from…

    It’s just a list of random branches, one per remote repository.

    PS: And git gc –auto does not do a very good job of keeping repository sizes stable

    That’s not an issue. If you want aggressive garbage collection, specify that (git gc –aggressive, or just git gc should be enough).

  102. @FelipeC: The last time I read the git tutorial was years ago, maybe that explains to you why I don’t take it for granted that when I get a set of commands I have to evoke a second command before that.

    So: Having the option of namespacing bookmarks which are in named paths would be nice, yes. I think to completely integrate that – including de-namespacing on push and possibly propagating the remote-namespace-information, so if you have a bookmark named bob/foo, but I have bobs repo as bobby I don’t get you/bob/foo, but rather bobby/foo – could take a bit more code.

    re mercurial extension: So you want me to improve Mercurial to deprecate your post? :)

    The problem I see with replicating your test is that you did not show how you pick the 10 random branches. How did you decide which branch to take? Just from the branch name?

    That’s something which should be part of the runtime of the video: finding out which branches are useful. Or it should explicitly not be part of it: “release time: integrate all release branches from all people”. Please define how to do the picking, then I can finish the missing piece in the hg workflow.

    PS: re gc –auto: that is just about your note that gc is no longer an issue. Repository sizes which rise and fall by a factor of 4 can be a big problem, so you still need manual garbage collection.

  103. @FelipeC: You told Jordi Gutiérrez Hermoso “but I’m sure they’ll give up, because they’ll recognize that it is indeed pretty difficult and tedious to do the same in mercurial. Feel free to prove me wrong.”

    The answer is: “9 Lines of Code”. And all following commands are easier in hg than in git. `hg rebase -b ` is easier than `git rebase –onto HEAD master `. And my mergetool gets called automatically.

  104. +Arne

    The last time I read the git tutorial was years ago

    Maybe you should do that again before claiming that git can’t do some things.

    mercurial extension: So you want me to improve Mercurial to deprecate your post?

    I want you to accept my challenge of doing what I did with git core commands using hg core commands (or extensions).

    The problem I see with replicating your test is that you did not show how you pick the 10 random branches. How did you decide which branch to take? Just from the branch name?

    What part of random don’t you understand? The ‘alice’ repo has 10 branches, pick one at random.

    I think I deleted the code I used to generate that repository, I will try to find it once more, and if I can’t, I’ll try to write it again, just to make sure.

    gc –auto: that is just about your note that gc is no longer an issue. Repository sizes which rise and fall by a factor of 4 can be a big problem, so you still need manual garbage collection.

    Nobody has mentioned the size of the repository as a problem (we even have a survey to find that kind of stuff), but I have raised this issue on the mailing list. Apparently, there’s already some work that would improve the situation, and probably there will be more:

    http://thread.gmane.org/gmane.comp.version-control.git/185083/focus=185089

  105. +Arne

    You told Jordi Gutiérrez Hermoso “but I’m sure they’ll give up, because they’ll recognize that it is indeed pretty difficult and tedious to do the same in mercurial. Feel free to prove me wrong.”

    The answer is: “9 Lines of Code”. And all following commands are easier in hg than in git. `hg rebase -b ` is easier than `git rebase –onto HEAD master `. And my mergetool gets called automatically.

    Please, stop trying to confuse the readers. I already mentioned why I used “git rebase –onto HEAD master “, and how it can be simplified. Do you want me to upload a new video with the simplified commands? Also, as you can see from the video, my mergetool gets called automatically too.

    And no, 9 lines of code is not the answer, because in git you don’t need any code, it’s already there. If you need to rely on some code, you need to type that code in the video challenge.

    If you keep bringing up things that were already discussed and resolved, I will remove those comments.

    hg –config extensions.boona=../pullnamespacedbookmarks.py pullnamespacedbookmarks -p boo/ ../mine/bab/

    Push it to mercurial, once it’s accepted as an official extension, submit the video, this blog post is not going anywhere, we can wait. I already said that. Or in the video, manually type the commands of the script, or manually write the script, or write the extension. IOW; you have to show all the steps needed from a vanilla mercurial installation.

  106. @FelipeC: Then I’ll show you all the steps needed from a vanilla hg installation. The steps needed now, because now the namespaced bookmarks extension exists. No worries: I’ll install it in the video.

  107. +Arne

    Then I’ll show you all the steps needed from a vanilla hg installation. The steps needed now, because now the namespaced bookmarks extension exists. No worries: I’ll install it in the video.

    No, you have to manually type the whole extension. Anything that is not part of mercurial core or official extensions you have to assume it doesn’t exist. Imagine this is a network without access to the Internet; no cheating from the outside. Because that is what almost everybody has.

    I wonder how is it not clear to you; if you have to write an extension: it’s not easy, nor straight-forward. But let’s see.

  108. @FelipeC: Sorry, I won’t waste my time with that. Just create the image in your head that I type the 1008 relevant characters at 300 characters per minute.

    Also you asked initially “can hg do this?” and the answer is: “damn yes”. By saying that I am not allowed to use an extension from the internet, you artifically skew the test in favor of git, which has no extension system. It’s as if you told me “let us compare Firefox and Internet Explorer, but you are not allowed to use Firefox Extensions”.

    Besides: I also create the test repos in the video, so it is reproducable.

  109. +Arne

    Sorry, I won’t waste my time with that.

    Exactly. Either that, or avoid your hacky scripts. In any case, what you do will be tedious, just as I said.

    Also you asked initially “can hg do this?” and the answer is: “damn yes”.

    You are wrong, this is what I said.

    You see in this video how in git:

    1) visualizing and keeping track of 100 branches is no problem at all
    2) picking 10 branches of those 100, and rebasing one on top of another is straight-forward

    I did all this in under 2 minutes with core git commands. Good luck trying to do the same in mercurial.

    Do you see the core part? That’s not what are doing.

    By saying that I am not allowed to use an extension from the internet, you artifically skew the test in favor of git, which has no extension system. It’s as if you told me “let us compare Firefox and Internet Explorer, but you are not allowed to use Firefox Extensions”.

    Again wrong. Mercurial extensions reside in “/usr/lib/python2.7/site-packages/hgext” and are distributed with mercurial. Your hacky script is not part of mercurial by any stretch of imagination, and nobody besides you have it in their machine.

    What you are doing is the equivalent of saying CVS has support for rebasing, because you can achieve it with your own scripts (or with quilt).

    You have failed the challenge. Try again when your script is distributed as part of mercurial in the ‘hgext’ directory. Then you can say mercurial does that in a straight-forward, and unproblematic way.

  110. @FelipeC: I kinda knew that you would reject this. You’re far too deeply invested emotionally in your perceived superiority of git.

    Would you also claim that Firefox plugins only count when they are distributed with Firefox?

    Oh, wait, Firefox is a web browser, and it uses web access facilities to install its extensions.

    Just like Mercurial uses source code management techniques to get its extensions: We clone their repositories.

    But I’m sure, you’ll reject that, too. As you will likely reject hg-git as advantage of Mercurial (a transparent bridge between hg and git repositories which I just used to contribute to Freenet using hg – something git cannot do the other way round). In Mercurial stuff does not need to be in the core commands to be part of the normal workflow – and fully integrated.

    But hey, you rigged the test against Mercurial, and I still completed it with that shell script (which you did not like, but then I don’t like your lengthy git commands either). I could just as well have used my shell command for retrieving the bookmarks in the video, but that would not have been as clean and rewarding for me. Just imagine the shell script instead of the extension, and this video is done with core commands. If you can’t imagine that, then do it yourself. I posted the script here. With your renicing of the shell commands, that’s even shorter than what I did.

    And the only reason for this extension is to show you that your claim of “namespaces are unique and super-special” is false. They are a cosmetic feature which can be added to hg as a <30 lines extension. Which now exists and is quite easy to get, use and activate.

    You want all that without extension? Do it yourself. After now having a way to deal with huge remote repo rebasing a bit more efficiently, I don’t see any more merit in this discussion.

    * Creating a namespaced bookmarks extension ✔

  111. Oh, and calling `git rebase –onto HEAD master ron/hermione` straight-forward and unproblematic is a joke in itself, which I’m sure most gits won’t get :)

    …well, at least there’s no doubting that it IS straight, different from `git rebase –onto HEAD master ron/harry`…

    *Bad pun buffer overflow…must stop this*
    *logging off chuckling*

  112. +Arne

    Your comments are way too trollish. This is the last warning, if you continue with arguments that were already debunked, trying to misinform the readers, I will remove your comments.

    Anyway, here is a new video challenge. It’s basically the same, but addresses some of your comments. Now I have explained the challenge itself in the video, and showed different commands to achieve the same result for rebasing. In the end, I used of course the simplest and most effective method. As you can see, your hg method is shown there too.

    You’re far too deeply invested emotionally in your perceived superiority of git.

    It’s not an emotion, it is superior. When you (or somebody else) answers the challenge, we can reconsider that fact for this particular scenario.

    Just like Mercurial uses source code management techniques to get its extensions: We clone their repositories.

    It doesn’t matter how you get them, they are not part of mercurial. This particular one can’t be found in a significative portion of the user-base. At best, 0.01% of users have this extension. You are cheating. By that reasoning, I can say that git supports watering my plants (see this) because I can add a script in ~/bin/git-plant-water (and run git plant-water), say, by cloning a repository (like https://github.com/felipec/git-plant-water). No, git doesn’t support plant watering, and mercurial doesn’t support namespaces.

    When your script (or something similar that allows namespaces) gets into mercurial officially (it’s distributed among other extensions in hgext), then you can say it’s supported. Period. Don’t bring this argument again, or your comment will be removed, I have explained that to you three times now.

    As you will likely reject hg-git as advantage of Mercurial.

    It is nice (although the same can be done in git, like it has been done with git-p4, it’s just that nobody has found enough motivation and time to do it), but it’s certainly still not part of mercurial.

    Although you can say that there are ways in which mercurial can interact with git, you can’t compare a popular extension with probably dozens of contributors that probably has a significant user-base (more than 0.01%) and is quite full feature-wise, stable, and mature; with your hacky script written in a few hours by one guy to demonstrate a point, no contributors, no user-base, and missing features that you yourself have argued would be nice to have. We are talking about diametrically different kinds of extensions here.

    You want all that without extension? Do it yourself.

    Maybe I will, just to show how horrible and painful it really is. It would be nice if you do it yourself, as I’ve really spent more than enough time writing the script twice, and posting two videos. And BTW, if you do it, make sure your commands are visible, because in the video you pushed, they commands are not visible at all. But I’m pretty sure you would not do it, as you yourself would realize the horribleness and give up.

    Oh, and calling `git rebase –onto HEAD master ron/hermione` straight-forward and unproblematic is a joke in itself, which I’m sure most gits won’t get

    You are bringing this again, even though it was debunked twice. As I’ve shown in the second video, you can achieve the same with ‘git checkout ingo/branch_8; git rebase master‘, and ‘git rebase master alexander/branch_8‘. I also explained why I chose that method; one command is more efficient than two. Moreover, as I already explained, that command can be simplified to ‘git rebase HEAD ron/hermione‘.

    Stop with your trolling and red herrings already.

    FWIW. The source code of the build script is here.

  113. I’ve used git at work for the last 4 years. However reading some of the points about mercurial brought up in the commentary, I think I should try hg!

  114. “However reading some of the points… ”

    What points are you referring to, Jim?

    Git is faster, Git has better compression, Git has better branching. Git has better tools, Git has better documentation, Git has better support from public servers, Git has better storage model… Git is easier to learn. own experience, I learned git and tried to learn hg at the same time because I had to make a choice at work…

    After looking at Arnes attempts to bendover backwards to try to prove the impossible, I my eyes, nothing really speaks in favor for Hg any longer.

  115. You mentioned how you hoped that your conclusions are not biased, but you didn’t really compare git and mercurial. Instead you just tried to show how old arguments about mercurial being better are wrong. I’d rather see a comparison about the ways in which mercurial and git are better than one another. (For example, patch queues in Mercurial are amazing)

  116. +blktigerlacktiger

    I’d rather see a comparison about the ways in which mercurial and git are better than one another.

    I thought that’s what I did, but I just don’t see any advantage of mercurial functionality-wise. What do you mean by patch queues? You mean Mercurial Queues? I don’t see anything special; you can achieve the same and more through core git concepts: cheap branches, rebase, staging area, etc. And it’s much simpler.

  117. Alas, poor Felipe! All this energy devoted from Jan 17 to Oct 14, just to prove that your choice is better than other’s… The fact that you ended up making a video totally amazed me. I pity you for not having better to do with your time and I admire the patience of all those who stayed polite when confronted to such a childish stubbornness.

    Anyway, I have learned a lot through this discussion, thank you all, and what I learned is that git and hg both do a good job, far better than svn, but also that git’s learning curve is the steepest.

    I’m looking for a DVCS that must be smoothly adopted by users that haven’t used a VCS in their life and they will accept my choice with a bit of anxiety since it will change their habits. Therefore, I’m looking for something easy to use and comprehend, not too far from cvs/svn for those who may have used a VCS in the past, something well integrated in various IDE on various platforms (from linux/vi to windows/eclipse), something with reasonable command line defaults.

    In this scenario which is the scenario of 90% of the companies out there, they will surely use at most 50% of the power of the tool, and we are surely not going to merge 100 branches from thousands of users. That’s why I’m starting with hg.

    Thank you all for your advice. If I ever regret my choice, which I doubt, I’ll leave another message here.

  118. Interesting discussion.

    Also nice to see that the Felipe was able to mostly stick with discussing technical issues despite getting personally insulted multiple times. I guess that’s what you resort to when you run out of real arguments.

  119. +Xavier

    So you concede the point that Git is superior in the use-case that I mentioned, you just want to downplay that use-case.

    In this scenario which is the scenario of 90% of the companies out there, they will surely use at most 50% of the power of the tool, and we are surely not going to merge 100 branches from thousands of users. That’s why I’m starting with hg.

    I used 100 branches just to make it crystal clear, but even if you use two repos, and a few branches, git already gives you a benefit precisely because of the same reason: namespaces. One example is having two repositories, a central one for development, and another one with the deployment (probably with a hook that automatically checks out the latest HEAD). This workflow, and many others, would be tedious in mercurial.

    +Niklas

    Thanks for the words of encouragement :)

  120. Xavier’s quote: “Alas, poor Felipe! All this energy devoted from Jan 17 to Oct 14, just to prove that your choice is better than other’s… The fact that you ended up making a video totally amazed me. I pity you for not having better to do with your time and I admire the patience of all those who stayed polite when confronted to such a childish stubbornness.”

    I’ve been following the discussion for some time and haven’t commented until now. The hypocrisy of this comment is repugnant – talk about childishness! I for one, am very appreciative of anyone who takes the time to help educate others. I have found the greatest challenge of learning open source software is the lack of documentation and adequate tutorials and comparisons. Had I not read this article and all its comments, I’d have no idea how to chose among competing products. Thanks to Felipe and the others who have participated in this discussion. I have been enlightened as a result.

  121. Wow, you talk about eduction, I see preaching.
    It’s just another stupid Linux vs Windows, OpenGL vs Direct3D, C# vs Java…argument.

    I for one prefer Cadillac over Porsche and I choose Mercurial.
    I wonder if FelipeC never got a word from the Git community to stop being such a little person.
    It gives a bad image of Git (in my eyes for sure).

    @FelipeC Repeat after me!

    I don’t want to be always right!
    It’s in the eye of the beholoder!
    Whatever rocks your boat!

    Open your mind and accept that some people may prefer and think of Mercurial as a better tool for their purpose. That’s all. Don’t try to convert everybody. Yes Git is a lot more powerful and mercurial is simpler. I don’t need all the power of Git but I like simplicity.

    Best regards!

  122. +Craig List

    This is not a matter of preference, I have put forward a use-case, and that use-case is not possible in Mercurial. Period.

    I don’t know what the Git community thinks of this post. But generally, I don’t think they believe in authoritarianism. This is what I think, and I should be free to express it.

    I don’t need all the power of Git but I like simplicity.

    So you accept Git is indeed more powerful… that’s exactly what I am saying. And maybe in the future you would like that power, hell, if you actually tasted it maybe you’ll want it now.

  123. @FelipeC: How did you get your script working? It doesn’t create more than one branch per repo – even after adding an origin repo.

    …wasted time again, hoping that there would be a good way now. Sidenote: your style can be frustrating, because you expect that others do quite some work to show that you are wrong instead of just trying the alternative they show you.

    The time I intended to use for a video was sucked up by trying to adapt your script – finding out in the end that it does not even work for git. I have no more time to waste today.

  124. +Arne Babenhauserheide

    How did you get your script working?

    ./build.

    It doesn’t create more than one branch per repo – even after adding an origin repo.

    Yes it does. You can clearly see in the video at 1:19.

    Sidenote: your style can be frustrating, because you expect that others do quite some work to show that you are wrong instead of just trying the alternative they show you.

    I have spent far more time than that. All you have to do is run the script, and convert the repository to mercurial. Do you want me to do that for you so you don’t have any more excuses?

    The time I intended to use for a video was sucked up by trying to adapt your script

    Adapt it to what? Just convert the resulting repo. Wasn’t the hg-git plug-in one of the touted “advantages” of mercurial?

    finding out in the end that it does not even work for git.

    Lies.

    Here, I’ll type all the commands:

    mkdir origin
    cd origin
    git init
    wget 'http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=README' -O README
    git add README
    git commit -m 'Initial commit'
    cd ..
    wget https://raw.github.com/gist/1357082/d51c382ee94c70d4bcefe2e3b46ddb96524c2e34/build.rb
    ruby build.rb
    cd mine
    git fetch --all
    git branch --all | wc -l

    102 branches.

    It literally took me only a couple of minutes.

    I think it’s pretty clear that you don’t even know how to use git, and thus have no idea what you are actually criticizing.

  125. ./build?

    $ ruby build.rb

    did now work for me. You stated that that had been the script you used, but you completely omitted the setup. You gave me one line and expected me to know the other 10 (not counting the wget).

    Your script did not create the repositories, so I wasted an hour where it would have cost you only a couple of minutes to just give the correct usage instructions – or make the script self-reliant. It can’t be that hard to add those 10 lines to the script. Do you consider it good style to pass on a script as proof which only runs if you use an undocumented initial setup?

  126. +Arne

    ./build?

    Yes, if the script is named ‘build’ and it has executable permissions. Since you appear to have problems figuring things out on your own:

    wget https://raw.github.com/gist/1357082/d51c382ee94c70d4bcefe2e3b46ddb96524c2e34/build.rb -O build
    chmod +x build

    You stated that that had been the script you used, but you completely omitted the setup.

    I explained the setup in my video, and there’s nothing special, you just need one repository with one file named README.

    You gave me one line and expected me to know the other 10 (not counting the wget).

    Again, lies. You didn’t have to know the other 10 lines, they can be inferred (do you really need me to explain “cd ..”?). You could have created totally different commands from those 10 lines, and it still would have worked.

    Here is an example with totally different commands:

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/kay/libabc.git origin
    ./build

    That’s it. You don’t need me to tell you how to download stuff, how to change directories. In fact, you don’t need me to tell you how to clone a git repo, or run a script. If you do, you are probably not qualified to be discussing at this level anyway.

    Your script did not create the repositories, so I wasted an hour where it would have cost you only a couple of minutes to just give the correct usage instructions – or make the script self-reliant. It can’t be that hard to add those 10 lines to the script. Do you consider it good style to pass on a script as proof which only runs if you use an undocumented initial setup?

    And more lies. I explained what the script needed in the video, and it could be used with any repository, as I just showed above.

    The script didn’t fail, it does its work perfectly. Either your repository didn’t have a README file, thus you didn’t bother watching the video where I explained so, or you didn’t run this command:

    git fetch --all

    Which again, is a basic command that anybody with a minimal knowledge of git remotes should know.

    And even if you didn’t run that, just going to any repo would show all the branches for that repo. The tedious part is creating the 10 repos and 100 branches, and my script does even more than that; it creates another repository and adds all the others as remotes. This step is not tedious, you could have done it yourself.

    Either way, neither ‘git fetch –all’ nor the ‘mine’ repository, nor the setting up of the remotes is relevant in mercurial context, so you could have just ignored those steps.

    It’s quite likely that you don’t even know how to use git, and now you are blaming me for your incompetence, you not only are not able to write a script of your own, you are not even able to understand or even run my script. Stop with the excuses and push the video where you are unable to deal with this use-case in mercurial.

  127. You may want to change “Projects using Git” and “Projects using Mercurial” sections to “Some projects using “, and list the same number of projects for each tool. Otherwise some may see it like you are lying by omission, considering that “Projects using Mercurial” section contains less projects and doesn’t mention such rather well known projects like, NetBeans, Wget, XEmacs, Xen, to name a few.

    Interesting review nevertheless.

  128. I’ve used both for a quite some time. git in my work environment and mercurial at home. I find mercurial to be far more intuitive. bazaar while clunky was even more intuitive at times, but I don’t use that anymore. For example, git uses odd types of notation: git reset –hard @{u}. There’s no way anyone can just look at that and be able to tell what it does. @{u} ? Gibberish.

    With “it’s all in the branches” you make a detailed explanation of what it looks like in git. All the commands involved. With hg, you just say it would be more complicated. You’re not leaving any room for anyone to make their own judgement based on the calls. I would have loved to seen the equivalent rather than take it at face value than “This is much more tricky in Mercurial”. It didn’t sound like you had it on authority that it was impossible, so if it was, I would like to have read that instead. The git version did not look simple at all. mergetool and rebase are terms which don’t have any inherent meaning, at least not to me.

    I suspect that git is also the only one which gets pages like http://think-like-a-git.net/ and git *is* hard to learn. mercurial isn’t.

    One thing I’ve liked a lot with bazaar is cherry-picking between branches. It’s very easy in bazaar and it’s obvious that when you’re specifying files to merge, you are doing cherry-picking. even the “term” cherry-picking is a very colloquial term for the English language and I would suspect is not at all easy for non-native English speakers to understand or remember.

    The justification that google should have chosen git because things got resolved is slanted as well. Many projects never fix issues, and there’s no guarantee. Hg did what google expected, and others expected. They certainly made the right choice at the time, and while branches in git still rule, I’m not convinced that should hold such a strong place for picking it as winner.

    Regular day to day operations in git need to be simpler.

  129. Daniel, I think you should also give a hg example how to do a git reset –hard @{whatever} before you ask FelipeC to do the same.

    You complain the the Git version looks complicated and that rebase and mergetool doesn’t have any inherrent meaning to you. If you have used Git in any proffessional situation, mergeltoola nd rebasse should be very well known words to you.

    The Hg community consistes of more people than one…While most of the Hg developers are hardworking people who wants to meke Hg better, some of the Hg evangelists are very aggressive in trying to attack Git. That is the reasons that there are a bunch of websites names “think like a git” or versions of it.

    None of the git critical articles I have seen has had any substance at all. No comparisons and no facts. Just some loose wordings like Git is dificult to use and Hg is easy. That was maybe true 2006.

    Then, about google… everybody have read the analyses that google made and most of it is just personal preferences…
    When google choose version control system for Android, the choise was Git. They have screved up everything with the “Repo” thing etc though which is a pity…

  130. martin: think like a git is actually written by a git user for other git users and is not at all agressive or trying to attack git. Did you read it?

    Based on your response I feel like I failed to communicate the point I was trying to make.

    git in my own experience has been less intuitive than mercurial. End of story. I like and use both.

  131. Daniel,

    Yes I have read the site some time ago (it’s quite well known) and I also re-read some of it now… and besides for being a really unstructured piece, it is written in a very sarcastic tone. It is not helping anyone…

    No you didn’t fail to communicate that you think Git is less intuitive than Hg, well I have exactly the opposite feeling, and I use booth Git and Hg too, but I don’t use that to tell people they should use Git instead of Hg. Driving on the right side may be more intuitive for you than to me.

    Tell people to get some real knowledge about both systems and then make a choice based on what they think is important.
    To me, the storage model is by far the most important factor. This is where you put your trust, your history resides there. If anyone tell you this is not important for the user then think again…

    Too many people make their choice based on the similarities with systems they migrate from… then why migrate at all?

  132. @Felipe, Would appreciate an explanation of the 9 commands that it takes to merge Bob’s branch. Thanks…

  133. Daniel,
    I assume you thing that “hg revert –all REV” is much more intuitive than “git reset –head @{u}” ? And you are probably right…

    Lets see how I would do it:
    Just open gitk (graphical history browser etc) , right-click on the commit you want to point your branch to and select “reset branch here”…
    You can do the same from the git gui…
    My point is, You have several ways of doing things. You can do it the complicated way or the easy way…
    To show your point you don’t need to present an example that is more complicated than the easiest one…

  134. +Daniel:

    For example, git uses odd types of notation: git reset –hard @{u}. There’s no way anyone can just look at that and be able to tell what it does. @{u} ? Gibberish.

    You don’t have to use that notation, you can use git reset --hard origin/upstream_branch, which as +martin points out, is not much different than hg revert –all REV. So @{u} is an extra, it’s syntactic sugar, but it’s optional, so it can only be an advantage, and you can use @{upstream} if @{u} confuses you.

    With hg, you just say it would be more complicated. You’re not leaving any room for anyone to make their own judgement based on the calls.

    The fact that you are missing is that there are no mercurial calls. That’s the whole point of the challenge, and nobody has answered the challenge. You can’t make a judgment call in commands that don’t exist. Which is the point being made: you just can’t do the same in mercurial. Period.

    If you think otherwise, please, answer the challenge, do the video, show the commands.

    I suspect that git is also the only one which gets pages like http://think-like-a-git.net/ and git *is* hard to learn. mercurial isn’t.

    On what are you basing that assertion? Your own experience? On the experience of the people you know? Isn’t that biased?

    Look at the Git User Survey results of 2010, most people say they find it reasonably easy. So what do you think is more statistically significant?

    Maybe some people find it easier, you just don’t know them.

    The justification that google should have chosen git because things got resolved is slanted as well. Many projects never fix issues, and there’s no guarantee.

    There’s no guarantee that the mercurial project would not collapse either, there’s no guarantee of anything.

    But chances are, the most active projects will advance at a faster pace, and resolve the real crucial issues.

  135. @FelipeC:
    Re: notation. Good point.

    Re: no mercurial calls. I did not read your post as a challenge. Merely that you were uncertain whether it could be done.

    Re: assertion. mostly my own experience. “git in my own experience has been less intuitive than mercurial”. I’ve not worked with anyone who thought git was as obvious as some alternatives.

    Re: guarantee. that’s true, but then by the same measure there’s nothing preventing mercurial from ending up “better” than git down the road too. Google made the call with the data they had at the time.

  136. +Daniel

    no mercurial calls. I did not read your post as a challenge. Merely that you were uncertain whether it could be done.

    Not the blog post, the video, which is described in the comments.

    Re: assertion. mostly my own experience. “git in my own experience has been less intuitive than mercurial”. I’ve not worked with anyone who thought git was as obvious as some alternatives.

    And quite likely those people learned SVN/CVS before git. Quite a lot of people that learn git before any other SCM find it easier to learn. In any case, you can’t really say git easier easier or harder to learn, the jury is still out on that one.

    Re: guarantee. that’s true, but then by the same measure there’s nothing preventing mercurial from ending up “better” than git down the road too. Google made the call with the data they had at the time.

    Of course, everything is possible, but you don’t go on through life checking every chair because it might be broken; we are probability machines and we make guesses based on that.

    As I said, chances are git would fix those issues, if you had asked me in 2008 if I thought Google made the wrong decision, I would have told you yes, and presented the same reasoning (as I did), and I would have been right, and I had the same data Google had, in fact probably less, but I had an insight that they apparently did not; the development practices and community of a project can tell you quite a lot about how they are going to be fixing their most difficult issues. Maybe I am wrong and there’s something else at play, but today with the data that we have, it looks like I was right in 2008, and Google was not.

    Moreover, some of their arguments were invalid right from the start, like the fact that they said history was sacred in mercurial.

  137. Git + Windows = Pain in the Ass!
    Thats a very very very huge argument. msysgit or cygwin is not an alternative to native software.

    So HG is better.

    Because it runs without ANY disadvantage on *nix or windows.
    Cluttered History? Is a repository history born to be pretty? History should be complete and not editable. Its HISTORY! Work on an “small branch feature” do not need a history branch…blabla….it does! 6 Weeks after you finished this feature you wanna jump back to a point in the feature….git show me how…ohh the branch died? tztztz…

    = Thats how i read your blog post, no really good arguments or anything.

    Use what you want, but if a peace of software is only good for you if it has more features then anyone need….hopefully you are not a developer :)

  138. Thats a very very very huge argument. msysgit or cygwin is not an alternative to native software.

    msysgit is native. It’s compiled with mingw32 which compiles win32 software.

    History should be complete and not editable.

    Then don’t use mercurial.

    Thats how i read your blog post, no really good arguments or anything.

    Maybe you should read it again when you know more about what I am talking about.

  139. @freakezoidDaniel You are just spreading FUD! Why are people writing stuff like this?

    I have used MsysGit + Windows professionally and daily since 2008…
    Everyone telling you that Windows is not well supported are just simply wrong!

    I have also used Git + Linux professionally and daily.

    I really don’t see much of a difference except in windows you have the integration in explorer so you can right click and start git gui or bash.
    In Linux under Nautilus I usually rightclick and start the terminal….

  140. This post – something that very few people need
    Good spam filter – to intercept comments from this thread, something awesome that a lot of people can’t live without.

  141. Command-line is a teletypewriter user-interface, used in the 70s.
    In last 40 years, most people used first CUIs, then GUIs.
    I know several programmers that cannot copy a file using command line.
    You shouldn’t compare Git vs Mercurial, but TortoiseGit vs TortoiseHg.
    And most people actually use TortoiseSVN, that is not distributed, because it is simpler than the other two systems, even if they need a distributed VCS.

  142. +Carlo Milanesi

    You are wrong.

    Command-line is a teletypewriter user-interface, used in the 70s.

    The fact that it was used in the past doesn’t mean it should not be used in the present.

    In last 40 years, most people used first CUIs, then GUIs.

    That’s an argumentum ad populum fallacy; the fact that most people use GUIs doesn’t mean CUI are worst.

    I know several programmers that cannot copy a file using command line.

    They most likely suck. All respectable hackers I know use the command line, in fact, the more respectable they are (e.g. Linux kernel hackers), the more they are familiar with it, and know more tricks about it.

    Similarly, most respectable hackers use vim (or emacs) rather than notepad.

    Command line is more efficient: period.

  143. I was just saying that to predict the success of a product among most people, you should see what dumb people likes, not what smart people likes. And most dumb people likes GUIs (or CUIs as a second choice) and dislikes CLIs.
    In additions, I think that most hackers are quite dumb for what regards user-friendliness: for example, there are tons of text editors created by hackers, but no one is really user-friendly; a user-friendly text-editor shouldn’t have a “save” command, as every keystroke should automatically save the contents.
    The failure of Linux as a client platform for most people is due to its excessive reliance on command-line interface and other technicalities.
    In my experience, many programmers come from a non-technical background, or they have never used Posix command-lines anyway. In many enterprises VisualSourceSafe and TortoiseSVN are used because they have a good GUI.

  144. +Carlo Milanesi

    I was just saying that to predict the success of a product among most people, you should see what dumb people likes, not what smart people likes. And most dumb people likes GUIs (or CUIs as a second choice) and dislikes CLIs.

    In general I agree, but regarding development tools, not at all. Then how do you explain that git is vastly more successful than mercurial, if mercurial’s interface is more user-friendly? And how do you explain the success of vim?

    In additions, I think that most hackers are quite dumb for what regards user-friendliness: for example, there are tons of text editors created by hackers, but no one is really user-friendly; a user-friendly text-editor shouldn’t have a “save” command, as every keystroke should automatically save the contents.

    You are making the mistake of assuming that user-friendliness is more important than powerful features; it’s not. Hackers want to be in full control of the interface, they know auto-saving would be more user-friendly, but that’s very low in the list of important features. Besides, saving on every key-stroke? What if this is on a network mount through a slow cellular connection?

    The failure of Linux as a client platform for most people is due to its excessive reliance on command-line interface and other technicalities.

    You must not know what Linux is; it’s a kernel, and it’s used everywhere; TV’s, supercomputers, routers, cars, stock exchange software, servers, phones, and now tablets as well.

    In my experience, many programmers come from a non-technical background, or they have never used Posix command-lines anyway. In many enterprises VisualSourceSafe and TortoiseSVN are used because they have a good GUI.

    Where they come from is irrelevant. Besides, subversion started with a command line interface, the “good GUI” came later, when it became clear that subversion was a winner. The same will happen (is already happening? with git).

    But those GUI’s are external tools that sit on top of the actual DVCS, and are hardly relevant to anything. Today the most perfect DVCS can have a totally crappy DVCS, but tomorrow somebody might decide to write an awesome one; that’s totally independent of the DVCS itself.

    An awesome TortoiseCVS GUI would not change the fact that CVS sucks.

  145. >> I was just saying that to predict the success of a product
    >> among most people, you should see what dumb people likes,
    >> not what smart people likes. And most dumb people
    >> likes GUIs (or CUIs as a second choice) and dislikes CLIs.

    > In general I agree, but regarding development tools, not at all.
    > Then how do you explain that git is vastly more successful
    > than mercurial, if mercurial’s interface is more user-friendly?
    > And how do you explain the success of vim?

    I have never encountered someone using Git in Microsoft Windows environment.
    Are you sure it is successful? I suppose it is used almost only in POSIX environments.
    Vim is used almost only by people having a Unix background. I have never encountered a programmer who uses Vim and who has never used a POSIX operating system.
    How do you explain the success of Microsoft Access and of Microsoft Office as a software development tools and of Visual Basic?
    How do you explain the success of Notepad as text-editor?
    Vim is much used under POSIX because it the standard text-editor in such environment; the same reason holds for Notepad.

    > You are making the mistake of assuming that user-friendliness
    > is more important than powerful features; it’s not.
    > Hackers want to be in full control of the interface,
    > they know auto-saving would be more user-friendly,
    > but that’s very low in the list of important features.

    You are making the mistake of assuming that most programmers are hackers. Most are just people who need a job to run a family.

    > The failure of Linux as a client platform for most people
    > is due to its excessive reliance on command-line interface
    > and other technicalities.

    You must not know what Linux is; it’s a kernel, and it’s used everywhere; TV’s, supercomputers, routers, cars, stock exchange software, servers, phones, and now tablets as well.

    You are wrong. I know that Linux is a kernel.
    And I know that it is used almost only in the ways:
    1) By people who does not use an interactive command interpreter (aka interactive shell).
    2) By students, advanced programmers, system administrators, who from occasionally to constantly need to use the shell.
    Most enterprise servers and most Web sites accesses come from people who cannot use a Unix shell and from computers who have no Unix shell available to users.

  146. +Carlo Milanesi

    I have never encountered someone using Git in Microsoft Windows environment.

    http://www.readwriteweb.com/hack/2011/12/infographic-what-tools-develop.php

    Vim is much used under POSIX because it the standard text-editor in such environment; the same reason holds for Notepad.

    No, that’s vi, and many distribute nano instead. And notepad is not successful at all.

    You are making the mistake of assuming that most programmers are hackers. Most are just people who need a job to run a family.

    You started mentioning hackers, not me, and you said they didn’t know how to implement user-friendly features. Why would they implement features that are irrelevant for them?

    And I know that it is used almost only in the ways:
    1) By people who does not use an interactive command interpreter (aka interactive shell).
    2) By students, advanced programmers, system administrators, who from occasionally to constantly need to use the shell.

    That doesn’t include Android phones and tablets, TVs, cars, stock exchanges, routers–essentially all the examples I already provided that prove you wrong.

  147. >> I have never encountered someone using Git in Microsoft Windows environment.
    > http://www.readwriteweb.com/hack/2011/12/infographic-what-tools-develop.php
    This survey doesn’t say which operating system was used by Git users. I suspect most of them didn’t use Microsoft Windows. In addition, they were “leading” software developers. I was talking of “average” software developers.

    >> Vim is much used under POSIX because it the standard text-editor in such environment;
    >> the same reason holds for Notepad.
    > No, that’s vi, and many distribute nano instead. And notepad is not successful at all.
    Vim is derived from Vi and it is used mostly by people who can use Vi.
    Likewise, under Windows, Notepad++ is used by people who can use Notepad. CUA editors are very successful under Windows environment. Notepad is not much used because most prefer to use a IDE containing a CUA editor.

    >> Why would [hackers] implement features that are irrelevant for them?
    To maximize the number of people using their software.

    >> And I know that it is used almost only in the ways:
    >> 1) By people who does not use an interactive command interpreter (aka interactive shell).
    >> 2) By students, advanced programmers, system administrators,
    >> who from occasionally to constantly need to use the shell.
    > That doesn’t include Android phones and tablets, TVs, cars, stock exchanges,
    > routers–essentially all the examples I already provided that prove you wrong.
    Android phones and tablets, TVs, cars, stock exchanges, routers belongs to category 1. They are used by people without using an interactive shell. For example, when you watch a Linux-based TV, do you use a Unix shell? Of course not. When you drive a Linux-based car, do you use Csh or Bash? When you trade stocks on Nasdaq, what is your prompt?

  148. +carlomilanesi

    This survey doesn’t say which operating system was used by Git users. I suspect most of them didn’t use Microsoft Windows. In addition, they were “leading” software developers. I was talking of “average” software developers.

    You can suspect whatever you want, but you have no evidence. I for one doubt “leading” developers would use Notepad++. Besides, you can see where the respondents come from; random small companies.

    Vim is derived from Vi and it is used mostly by people who can use Vi.

    Wrong. There’s plenty of people that can use vi, yet they choose emacs. People use vim because it’s awesome.

    Likewise, under Windows, Notepad++ is used by people who can use Notepad.

    You must be joking. Anybody can use notepad. Notepad++ is successful, Notepad is not.

    To maximize the number of people using their software.

    It’s more important to improve it for the users that matter; starting from themselves. There’s an endless list of things to do just for those.

    Android phones and tablets, TVs, cars, stock exchanges, routers belongs to category 1. They are used by people without using an interactive shell.

    It’s still Linux, and it’s not a failure as you said.

  149. > I am biased (but I hope my conclusions are not).

    You fail at being unbiased, especially with this comment.

    “My objective is to show why Git is superior.”

    You should be up-front about that.

  150. +Connor Irrelevant. Had the results showed mercurial was superior, or even, I would have had to accept that. That was not the case.

    Instead of attacking my motives, why don’t you tackle the analysis? In which way is the analysis wrong, or skewed?

    After 177 comments, I doubt you can bring anything to the table that hasn’t been already debunked.

  151. Hg have named branch. Git haven’t.
    Normal development without named branch is impossible.

    Open linux kernel git repository.
    THEY USE COMMENT TO MARK FEATURE!!!
    Give me a microscope that would nail the nails!

    Mercurial save branch history in remote repository(remote branch in git) after merge. Git don’t save branch history in another branch.
    That is all distinction, but its BIG distinction which have influence to all workflow.

  152. +sowingsadness Show me a single thing you cannot do, or is difficult to do with Git branches. In the comments above people have tried, and I have showed how you can always achieve the same.

  153. +FelipeC
    Simple example of master branch with two featuries(f1 and f2): http://goo.gl/204jB
    each feature developed in own branch.
    Feature f2 have a big bug and was merge last in master branch and 1 commit to master branch.
    We ned revert system to stable state.
    Pls, write solve this problem.

  154. +sowingsadness

    I don’t understand your English. It’s a single command, and most of the time you don’t need to specify anything other than ‘-m 1′, if that doesn’t do what you want, then ‘-m 2′ (but that’s unlikely). That’s not difficult at all.

  155. Which of commit(merge) we need to revert?
    The last merge is not always a problem.
    Which parent-branch we should choose as a major?

  156. +sowingsadness

    Which of commit(merge) we need to revert? The last merge is not always a problem.

    So? git revert -m 1 $merge_commit. This can be any commit, it doesn’t have to be the last merge. I even provided you with a real example (the merge commit reverted was not the last).

    Which parent-branch we should choose as a major?

    As I said, you usually just do ‘-m 1′, and I can try to explain you with examples why is that the case, but in the unlikely event that is not the case, just try -m 2.

  157. I’d have to agree that Mercurial is easier to use. Maybe only for those of us who have been exposed to other tools. The thing that made the decision for me, though, was the Git culture.

    I’ve been exposed to many groups who LOVE their tool, like Lisp or the Mac. They don’t bother me. But the Git culture is more like some Linux and Windows users who can’t simply advocate for their choice: they have to aggressively trash the alternatives and those who might use them. You can hear the “… and your little dog, too!” at the end of every posting.

    If you asked me to analogize the two tools, I’d say that Mercurial is like Python, while Git is like Perl.

  158. +Wayne2 Git is like Linux, Mercurial is like QNX. QNX might be more user-friendly and appealing than Linux, but Linux is more powerful and a unstoppable behemoth, and you can’t to anything about it.

    If you don’t use Linux because of all the people that say Linux is awesome, and you can’t convince them otherwise. Well, maybe, it’s because they are right.

    Don’t confuse Mac’s cargo cult with Linux’s evidence-based awesomeness.

    Maybe git truly is awesome, and when I say git is awesome, I’m not lying, or being confused. If git is awesome, and I think so, what would you rather have me do? Lie?

  159. Pingback: No, mercurial branches are still not better than git ones; response to jhw’s More On Mercurial vs. Git (with Graphs!) « Felipe Contreras

  160. @carlomilanesi

    > When you drive a Linux-based car, do you use Csh or Bash? When you trade stocks on Nasdaq, what is your prompt?

    When I drive a Linux-based car, I prefer to use bash on other cars. I have stopped doing this recently as the insurance company does not like me doing it.

    When I trade stocks on NASDAQ, my prompt is $. Obviously.

  161. Quote: ‘so I am biased (but I hope my conclusions are not).’

    No, you sound pretty biased actually. I’m currently ploughing my way through working out git. Thinking I might just try mercurial. Some of your rants are a good advocate for trying it.

  162. @Scott That’s nice, but that’s not enough. To have truly effective branching you need support for remote name-spaces: alice/master, bob/master, etc.

    I don’t think this extension does that.

  163. Hi Felipe!

    Sorry for resurrecting this thread after this long time, but one of your comments suggested that you have a solution for one of my problems.

    One of the comments pointed out, that you destroyed the branch of the 10 users you’ve selected.
    You replied that they just need to rebase for themselves before they can resume work.

    Can you elaborate on this a bit?

    Assume you have the following setup:

    User A
    A – B – C<- (master)
    \
    D <-(topic)

    User B:
    A – B – C <- (master)
    \
    D – E <-(topic)

    When user A rebases then (and pushes):

    A – B – C<- (master)
    \
    D' <-(topic)

    After User B pulls:
    D' <- (origin/topic)
    /
    A – B – C <- (master)
    \
    D – E <-(topic)


    (At least this is my understanding.)
    How to recover from this situation?
    How to detect this situation?

    Another thing, that I don't grasp at the moment is, in case I decide not to rewrite history (no rebase, basically due to the above thing), then how can I see what was the master at a given time?
    In case of many concurrent topic branches I was not able to follow it, because as you said, branch is only a ref, after that moves it will be a just a chain of commits… …and every commit is the same on the graph.
    Is there an easy way to follow a branch in history?

    Background, we have to support more major versions concurrently. So in case I would like to merge a feature to an upper version I need to have the commits belonging to that topic branch. In case I used merge to "update my topic / rebase(clearcase slang)", then the topic branch in the history will only point to another "chain of commits" (which used to be the master) at that point of time. "merge-base" might help here, I did not tried it out yet I just learned about it in your comments above.

    How can I say exactly what needs to be in for "cherry-pick"?

    I would like to achieve this:
    A-B-C <- (topic-1.4)
    / |
    F – G – H <- (release-1.4)

    X-Y-Z <- (release-1.5)
    \
    A' – B' – C' <-(topic-1.5)

    (I'm not even sure whether "B" (which is merge of G) should land there!)

    Nevertheless, I like git's internal stuctures. The idea is very simple and everything is a combination of this simple idea. This keeps things safe and easy. It is also granted that in case you know the guts of it, then the commands will begin to make sense. The help in the "git status" helps much in the beginning.

    Eg. sometimes I wonder between:

    rm –cached
    checkout –
    reset HEAD

    They don't seem to say what they do or easy to confuse. (They do, but only if you _understand_ the internals _well_)

    For me:
    stage / unstage / revert
    seems to be more intuitive. (maybe due to my SVN history) Alias is very big help here.

    Also from git's perspecive you are "adding" a remove to the index by "add" the removed file, but this is still a bit unusual for me.

    "Add" is used for adding to the index (for eg. updates) and adding to the VCS.
    So I need to "add" the file every time to the VCS to have it commited. Again commit -a, and GUIs masks this away. Knowing that in Git each commit logically just a bunch of files, a subtree and if you look from there to down you see the whole repo by adding commits as layers, then it makes sense.

    Checkout is also a bit confusing at times. You can change view / create branch / revert modifications with the same tool.

    I think the reason why people tend to say HG is easier to learn is, that they only need to learn 2 more commands to SVN/CVS and then they can continue working. This was my case, I was able to get working with HG without reading too much about it. Just push/pull and that was all, plus with all the benefits of a DVCS already there.

    With Git you really need to learn a bit about it before you can fly. After reading much on the net (also one of my collagues compiled a nice intro for the team) I begin to grasp Git, but not before.

    Cheers,

    Tamas

    ps.
    …and I don't like to feel guilty about using/learning SVN in the past at Git this is something which annoyes me a bit.

  164. So you have:

    User A
    A – B – C<- (master)
    \
    D <-(topic)

    And after the rebase:

    A – B – C<- (master)
    \
    D' <-(topic)

    So you didn’t change anything! You need to rebase on top of master, then you have:

    A – B – C<- (master)
             \
              D' <-(topic)

    Then B sees:

              D' <- (origin/topic)
             /
    A – B – C <- (master)
    \
    D – E <-(topic)

    And no, when you rebase topic branches for new releases you shouldn’t cherry-pick merges.

    As for the rest, yes, I also think some of the terminology needs to change to be more intuitive, and I think it will be done, but it will take time.

  165. “So you didn’t change anything! You need to rebase on top of master, then you have:”

    I ment D’ is on the top like you said, just I was not able to get fixed font in my comment.

    “Then B sees:”

    This is exacly what I “expect”. The question is how can I recover from this situation?
    I would need to give some advice to the others in the team, because this will happen I guess.

    I got one advice from a friend, that after rebase rename the branch and push it again and everybody needs to change, but this sounds scarry to me.

  166. @Tamas Then B rebases topic on top of origin/topic. It’s not the best, but that’s why you should avoid rebasing topic branches until you want to merge to master.

  167. Ah, OK. Just noticed the bit about Hg users there.

    By the way, I’m wondering if you still have the script (or whatever tool) that you used to create those test repositories that you used in your rebase example ( http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/#comment-6387 ). I would like to examine the example and try to reproduce it, and then try to see if Mercurial in its current state can do the same. I have a feeling it can, given its now core (and arguably more elegant) support for namespaced bookmarks.

    Reproducibility would be really important here–i.e. starting from the same initial data set.

  168. @yawaramin I posted a new challenge, and also the script here.

    However, since I’ve written git-remote-hg, I’m much more familiar with Mercurial now, and I can see that the challenge simply won’t work, because all the bookmarks would clash with each other. Also, you can’t easily remove bookmarks in Mercurial, or at least, the commits in them, you need in addition to do ‘hg strip’, and do the same in the server, it’s certainly not convenient, specially when the bookmarks are not yours, but from a remote that you added.

    I’m not sure if I mentioned in the video challenge that there shouldn’t be any left-overs, but they shouldn’t :)

  169. Pingback: Ishtyaq Habib | Know Your Git - Ishtyaq Habib

  170. Pingback: An in-depth analysis of Mercurial and Git branches | Felipe Contreras

  171. Have been using git for the last 4-5 years at work. I’ve gotten mostly used to it, but no doubt it was a big struggle at the beginning. There were so many strange things that used to happen — detached heads, history getting rewritten unexpectedly, lost history etc when I would try some command from google, but it ended up doing something else that I didnt expect, and boof, the repo is in a mess. I have got the hang over time, but again every time we have to introduce someone new to it, and things become a mess.

    Have not read a whole lot about hg. But ironically, this post, instead of convincing me about the superiority of git has instead intrigued me about hg. Now I’m really interested in all the other branching models, and patch queues that hg provides. Plus the usability feature of not accidentally screwing up the repository would be a big plus. I think I will migrate my personal projects over to it and check it out.

  172. Sid, sorry to say, but please don’t bother. First of all, you’ve invested a long time mastering git. Learning a new system will only waste your time that could be used more productively. Second of all, it’s not worth it to move from one technology to another technology of the same generation and roughly the same level of advancement. Git and hg have roughly the same feature set with some UI and other advanced-level differences. I could understand going from an older technology to a newer one which introduced a paradigm shift (e.g. svn to hg/git), but moving sideways isn’t really worth it.

    By the way, my answer would be the same to some who spent the last 4 years with hg and was looking to move to, say, fossil. But if I’m being honest, if someone were looking to move to git from hg I would actually say go ahead, just because with the network effect, git has a greater userbase and therefore bigger community.

  173. Well, that may be true. I had thought all this time that it is an almost 1:1 similarity between git and hg, but it looks to me from the comments that the paradigm itself is quite different, eg: using patch queues instead of index or bookmarks instead of branches. In that case it may be useful to learn on personal projects, eg: like learning a functional language when you know OO, maybe?

  174. Hmm, not sure I see patch queues as being analogous to the index. The index is basically a single patch. The closest hg comes to it is when you add ‘hg add’ new files and they have the status that they will be added to the repo on next commit.

    Also, hg bookmarks are _exactly_ the same, conceptually, as git branches. The implementation may be a little different; hg developers tried to simplify things with branches as much as possible so you don’t have to juggle both the local ref and the remote ref. But again, not a paradigm shift.

    Anyway, to my eyes svn is like OO and git is FP.[1] :-)

    [1] http://www.jayway.com/2013/03/03/git-is-a-purely-functional-data-structure/

  175. By all means, if an editor as advanced as powerful as vim confuses you, stay with a less advanced editor, like Notepad+. Similarly, if Git’s power confuses you, stay with Subversion, or whatever is easier for you.

    I would rather learn and get all the power.

  176. I’m a few years late to this, but thought I’d chime in. I just recently started to learn git, only because I forced myself too. The thing that makes mercurial 20 time more preferable for me is third party tools like the TortoiseHg workbench. Git has nothing remotely approaching that. I can deal with the branching mess, just by closing hidden branches.

  177. I completely agree with MikeF and must say, that Felipe’s conclusions are just as biased as the rest of the article. The article does enumerate a very extensive number of topics, however, only git solutions are presented and the often simpler and safer mercurial alternatives are ignored.
    Why not give pointers to the differences and let the readers decide, what is an advantage and what not?
    Apart from that, I wonder why there is so much poison in git users, whenever anyone mentions mercurial. Git has nothing to fear, because it already had the “market” before mercurial started out. That market share advantage will probably never be compensated, because developers mostly stick to their established ways.
    Let’s just be happy, that there are alternatives for all kinds of users.

  178. “You are wrong. Git and Mercurial started at the same time. Git won because Git is superior in every way.”

    I think Git “won” (if won; or if there was a fight at all) because people though it is sexy because it is done by Linus, it must be good, even if it was not meant to be a general purpose tool at first. Also Git people are much more loud and concluded that Git won. The amount of users does not correlate of the quality of the product. Timing, “marketing” an already established brand (Linux) matters much more than that.

    I’m using both Git and Hg successfully. Git is very visible on the web, because you need to decide many things upfront to use it (rebase/ merge, how to keep the history clean so you can follow developer branches) and people discussing it endlessly.

    The main difference is in my opinion, that in HG “branch” is a first class citizen, because there are people who think that it is important to know later on which branch the development was done. Git does not have this information, just a “bookmark” which shows the tip of the branch, no information of the past. Just nodes.

    According to Git it is useless information. In case of open-source projects with many one-off contributors and random naming habits, I can follow this line of though. At our organization we need to know that, also we need to be able to take these changes to another major version later.

    We do it with Git, but we did not get not much help from Git to achieve this. (Git does not tell you where did a branch came from, also it cannot tell which line is the main branch without knowing the parent branch)

    From my opinion and for my use-case Git is not superior for our case. Why we choose it? it is a long story, but technical qualities were less involved…

    For your use-cases Git probably wins hands down, but people have other factory you don’t know or care about.

    Cheers,

    Tamas

  179. @Tamas

    I think Git “won” (if won; or if there was a fight at all) because people though it is sexy because it is done by Linus, it must be good, even if it was not meant to be a general purpose tool at first.

    And I disagree, I think Git won because of its datamodel. It’s very very simple, yet so powerfull.

    For your use-cases Git probably wins hands down, but people have other factory you don’t know or care about.

    I’ve spent a lot of time discussing about this, I know every possible use case other people might have. Git can do absolutely anything. There is just one exception, and I have the patch that enables it, if it was really that big of an issue, the patch would be aplied to the mainline Git, but it’s not.

  180. And I disagree, I think Git won because of its datamodel. It’s very very simple, yet so powerfull.

    I think most of the people in this industry just sheeps: Follow a leader. “You know, 1 million developers cannot :beeee: wrong”. I agree that git is has a simple data model. This made possible that it was stable very quickly. Still I don’t care about datamodel of a VCS, I care about MY datamodel much more. This is here Git failed in my oppinion: EVERYBODY have to care about Git’s -super easy- datamodel, because otherwise you cannot comprehend the commands. They only make sense if you understand FULLY the implications of this easy model. Git is like assembly, you can do everything, you need to know everything.

    I think Git has two unadmitted deficiencies. Unadmitted is a bit soft, because Git is PROUD of these. Both of them could be addressed realtively painlessly.

    1. is a lack of true branch support.

    Yes, if you keep your history clean, branches are visible (or invisible how you like it), then you can follow it clearly. Otherwise it is a large blob of interconnected nodes with some of them has a post-it on.

    We tried to keep it clean. We started using ‘git pull –rebase’, refresh branch with rebase, easy as pie.
    But then suddenly the branches are messed up if two developers are using the same branch, because rebase rewritten the nodes and put the post-it on the new one. Well, we could use merge instead and only at the end rebase – we thought.
    Oh, but then you have to apply the merge AGAIN step by step and then suddenly rebase stops at the merge node puzzling where this came from? Where should I calculate the delta from?
    Yes in this simple model you always need two nodes to generate the delta and you need a delta to rebase!
    Well you could specify this with switches which was the main branch and which is yours. Of course rerere will replay your merges so you only have to do what was not merged and everything cool. This is where my complexity circuit-breaker melted. I don’t want to care about all this.

    We spend more than 100 hours to make it work for us in a way that we can rely on it and still once in a while Git leaves some poor guy with a half baked commit with some bogus merge errors. Never figured out what happens there, because everything seems fine if we investigated it and the command executes without an error from any other computers, but that one. Yes we could roll back the change and this is really an asset of Git: it is hard to screw it totally. Still the merge command fails. Solution? clone a new repo.

    2. lack of rename information.

    This is a very annoying thing, because Git folk says that rename info is redundant and it can calculate it anytime better than storing it. But yet in reality you need to twiddle with rewrite percentages and node counts to get it working properly in case you would like to operate with a bit more files in a bit diverged tree.

    It is not like I don’t like than I can rename a file with any tool and let Git figure out, but I committed the change it is not going to change forever; making it unpredicatble for a sake of some bits on the drive is beyond explanation.

    I’ve spent a lot of time discussing about this, I know every possible use case other people might have. Git can do absolutely anything. There is just one exception, and I have the patch that enables it, if it was really that big of an issue, the patch would be aplied to the mainline Git, but it’s not.

    If you would see the world from my perspective a bit: I have a usecase which is determined by Git developers as wrong/invalid. Would you still say, that Git won or superior in every aspect? Would you be happy to hear that your usecase is unimportant even better not a valid usecase?
    I think this is the very problem with Git. If something does not fit into this, then it must be wrong.
    Eg. Git folk frown upon SVN folk because SVN is wrong. If you are using SVN you must be stupid. In fact most of the people don’t get the chance to choose VCS, they take what is given.

    Cheers,

    Tamas

  181. If you would see the world from my perspective a bit: I have a usecase which is determined by Git developers as wrong/invalid.

    I do see the world from your perspective, and your use-case is perfectly supported by Git. You are just wrong.

    One million developers can be wrong, but in this case, they aren’t.

    Git supports every use-case, everybody knows this, you are just using Git wrong.

  182. I do see the world from your perspective, and your use-case is perfectly supported by Git. You are just wrong.

    Please tell me how to use it right.

    We have 2-3 major versions of the software. We would like to work isolated from the main branch so we would like ot use topic branches. Sometimes a bug happens on an older branch we have to merge it upstream in this case. Sometimes more than one developers are working on the same branch. Sometimes it is needed to refresh the topic branch so it containts the latest features.
    Most of the times we integrate the branch already (and delete) when we have time to move the bug up.

    If it is so easy, tell me which git commands should I use exactly to create one branch on the lower version , refresh it and then integrate it. Plus move it one version up in a way I could put it in a script. (like git-flow).

    Cheers,

    Tamas

  183. @Tamas There’s plenty of tutorials that tell you what you want. If you really need help on how to use Git, I’m sure you can hire people like GitHub to do Git training within your company. At the very least ask the question in an appropriate channel, like StackOverflow.

  184. Dear Felipe,

    You said that it is super easy, I just took your word: show me. I interpret your comment as a retreat. As I said I know how to do it, but it is not trivial nor easy.

    I’m just very upset about people claiming that something is “superior” and “knows every usecase” and then it turns out that it doesn’t or that super elegant simple data-model does not support some use-cases. Of course then this use-case is an insult.
    This is were HG won, the community is not hostile against the users and their probems.

    You don’t have to answer to this comment, you already considered my use-case as invalid and my usage as wrong.

    Cheers,

    Tamas

  185. @Tamas

    Where did I say it was “super-easy”. You are lying about what I said.

    I actually think your use-case is pretty straight-forward, but you are not explaining it well, but I’m not going to ask you to clarify it more. This post already 220 comments long, it doesn’t need more back and forth, this is not the medium.

    Go ahead and post it on StackOverflow, I would be happy to answer you there, or even better, use the right medium; the Git mailing list, it’s one e-mail away, you don’t need to subscribe. You haven’t done any of those things, you are using this blog post as an excuse, I am not “the community” go contact the actual community.

    you already considered my use-case as invalid and my usage as wrong.

    Lies.

  186. I work in computational physics.. our research includes producing/adding to/upkeeping a few widely used simulation packages. We have used SVN and are now (after much prodding) upgrading to a DVCS, I have been researching into which one to use.

    I was on the fence between HG and GIT. I am now leaning towards HG because of the ease of use. I tried an internal test where one project was put on HG and another in GIT. By the end of the test, no one was even using the GIT server because there were just enough complications that it caused enough annoyance that people stopped using it and went back to just storing multiple version locally.

    I think that FelipeC does not give the issues of ease-of-use and ‘compliance’ (ie. users actually using the DVCS) enough weight. From my experience, there were many little surprising issues that pop up with GIT.. enough that to use GIT you really need to understand a lot about the internals of GIT to really use it ( let me be clear: of course once you know GIT it is super reliable and us can fix all these issues easily)

    And just to get to brass tacks: I am lucky to work in an environment where everyone is quite smart and not adverse to technical details (everyone is a PhD in CS or physics or towards the end of their PhD).. and GIT just annoyed them enough so that they weren’t willing to spend time on it (and I must add in that most of the people doing coding are grad students who are there for a few years and leave.. so we have a flux of people and so we are have to train new students.. so ease of use is important)

    As for my personal experience: my PhD is in computer science (granted it’s in theory so I am not much of a ‘hacker’) and I found GIT to be a bit complicated to just ‘get things done’ (even though I appreciate the GIT’s commitment to be thorough in solving a problem that is rife with complexity)

    And one more pet peeve: I think that FelipeC’s attitude is just not helpful… when I teach classes, I reserve 15% of the grade for attitude/class room participation and… it drives some students/faculty nuts, but ‘attitude/class participation’ are worth way more then 15% in real life… I take no pleasure but I’ve had to give Bs/Cs’ to some really smart kids (who have never gotten a ‘B/’C’ in their life).. but some lessons are more important. I will not silently encourage the production of more snarky nerds who don’t understand that other factors besides ‘being right’ matter. There are certain communities have way too much of this (standouts are the C++ community or some pockets of Linux) and, at least to me, GIT is one of them (as represented by some of your comments).

  187. Hi. My first question to you would be, why are you even looking at a DVCS if you’re happy with svn? svn isn’t going anywhere, and if it works well enough why mess with it? If you’re saying that someone is pushing you to do it, then I would ask, are they pushing to just go to a DVCS, or to go to git or hg specifically?

    If the former, I would recommend you push back and ask for a specific recommendation instead of a vague ‘use a DVCS’.

    If the latter, I would suggest you ask them to become the ‘champion’ within your group of the system they’re recommending. This would mean convincing people (presentations etc.), training users, explaining concepts, fixing problems on an ad-hoc basis, perhaps even maintaining the centralised repo (although since you’re clearly an educational user GitHub will basically give you private repos for free). This should either damp down their enthusiasm to disrupt everyone’s workflow for the sake of a shiny new toy, or push them to help make a qualitative change for the better in everyone’s workflow.

    I will also say this. If you go with hg, you should know that at some point your users may become frustrated with some of the limitations, do a little research on git, and then push you to move to git! Or vice-versa. So you should be prepared for both eventualities.

  188. @lookingatdvcs Thanks for your comment. The one about attitude is right on the mark.

    @Yawar Amin Your comment about users becoming frustrated by hg limitations sounds like FUD to me. I could counter that git allows you to do things that can really shoot yourself in the foot with. Or even that getting anything done with git requires knowledge of a lot of arcane command line flags.

    Anyway, they are both GREAT tools, at an excellent price (free!!) and either is a fine choice for a DVCS.

  189. @hohonuuli: I’m having a hard time understanding how it’s FUD to say that users of git OR hg could equally become frustrated and want to move to the other after a while, so it’s good to be prepared for that. You’ll have to explain that one.

    Also, I wasn’t going to say anything but I disagree about the attitude thing. I hope this person isn’t going about making workplace decisions based on blog posts and comments of random strangers on the internet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s