Hacker News Reader

Comment by mikro2nd | Hacker News Reader

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days

I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses?

I believe that much of the popularity of git stems from github making it very easy to adopt, something that bitbucket doesn't seem to have pulled off as well.

View on HN

Yep, I don't understand the author's assertions about Mercurial either.

Mercurial remains a better choice for a few use cases where git simply falls flat.

Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension.

And realistically, perforce or other solutions appear to be even more popular among that particular developer segment.

Personally, I use Mercurial wherever possible, but that's not because I believe Mercurial to be technically superior, it's just because I hate git's UI.

Perhaps among the general FOSS community git is more popular, but both git and Mercurial have yet to met the needs of many developers.

Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension.

Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.

  Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.

Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4.

Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a large following among the corporate world. And many of the largest tech companies I'm aware of don't use p4 primarily; they use git, mercurial, svn, cvs, SourceSafe, home-grown solutions, etc.

Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.

You're right; I had forgotten about TFS.

Disclaimer: I'm not a Microsoftie, just collecting some links and adding my own opinion.

Microsoft use TFS heavily [1].

Right now I imagine most MS projects are TFS but it doesn't appear to be mandated. Maybe for the big, internal-only stuff. ASP.NET is hosted on CodePlex as a Git repo [2] and MEF is Hg [3].

They've just added Git support to TFS and that probably means a lot of MS projects will migrate to Git over time.

[1] http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/t...

[2] http://aspnetwebstack.codeplex.com/

[3] https://mef.codeplex.com/SourceControl/latest#.hgignore

Guess you need to tell Facebook and their repo that "many times larger than the Linux kernel" to grow up, because they're using Mercurial and have made lots of improvements to it: https://code.facebook.com/posts/218678814984400/scaling-merc...

Git now has the git-annex extension for large files; I use it myself for all my data.

http://git-annex.branchable.com/

It's not the same thing. That only stores the latest revision. You can't easily go back in history and check out earlier revisions of the large files. You can in hg.

Yes you can.

I've noticed this, oddly, while my workplace is transitioning to git from Mercurial.

A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. It's why I always preferred using Mercurial. A few .NET shops that use TFP/VSO are moving towards Git for the Visual Studio support, but I've noticed a few Python and PHP developers making the switch to Mercurial.

To be honest, I rarely need to do anything more than the basics so neither has a huge benefit for me. Neither feels particularly faster than the other, and both have comparable GUI tools. Aside from when I am pushing stuff to GitHub I tend to use whichever one pops to my head first on a project. I reckon a lot of developers are probably the same.

It seems that most .NET devs prefer something baked straight into Visual Studio and my experience has been that this is part of the problem in getting those teams to migrate to Git, which is most powerful from the command line.

Personally, I greatly prefer my source control system to be separate from my development environment or IDE.

Microsoft released a git plugin for VS.

Git's pretty well baked straight into Visual Studio now that it's built into the latest version of Team Foundation Server.

Mercurial's the one where you really want to be using it from the command line. It's had VS plugins, but they're all kind of janky by comparison.

Or use TortoiseHg or SourceTree, if you're not comfortable with the CLI. They both work great. Also, if you need to host 'your own github', try RhodeCode.

> A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows.

In my opinion it is more elegant. Git only works because it installs hacked up Linux utilities on Windows. In practice it might not matter but I feel dirty when I'm using "inelegant" solutions.

I guess it's a matter of taste or opinion but Mercurial is easier to use too. Though if you're just working on something solo the SCM doesn't really matter at all, you just commit and commit (and I mainly work solo).

Personally I also write mostly in Python so I'm naturally drawn to Mercurial.

Then again I've also been looking at and using Fossil for my projects because it's a single binary with no installer which makes it pretty cool in my opinion. It too works well and it's used as SQLite's SCM so I'm confident it won't screw up my projects. The other nice thing (although I haven't used them extensively) is that Fossil also includes an embedded web server that has a wiki and ticketing system so everything's integrated.

"Then again I've also been looking at and using Fossil for my projects because it's a single binary with no installer which makes it pretty cool in my opinion."

It actually relies on some configuration files in user's directory. I had troubles even launching it on a heavy-modified OS. I assumed it was a pretty simple and straightforward CLI tool that could work on bare-bone operating system. I was wrong!

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress.

What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.

The success of git is - apart from the speed - related with its property of being the "stupid content tracker".

Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system.

The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.

Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows.

Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined.

After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.

> the desire to support arbitrary workflows.

Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch.

git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.

> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from"

What? Of course you can. I've worked on teams that did it. You are talking total rubbish.

I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different.

How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.

Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to.

I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through.

It isn't the way that I prefer using git, but it works perfectly well.

> Set up a repo on a server somewhere and declare it to be the "central repo"

That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).

Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit".

If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow.

If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.

> Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit".

Sure, but you hit the problem twice as often in git, because you have to do twice as many things.

> If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.

In SVN that doesn't show up as a merge in the history.

In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.

> "Sure, but you hit the problem twice as often in git, because you have to do twice as many things."

Well no, I don't...

If this really is a frequent problem for you, then you might want to consider adding a note to the end of git-commit's output to remind you to push, or even just aliasing git-commit to push by default. I would recommend that you instead learn how to use git, but failing that...

> "In SVN that doesn't show up as a merge in the history."

If you don't want to resolve those situations with a merge, then don't resolve those situations with a merge... Rebasing exists for a reason.

> In SVN that doesn't show up as a merge in the history.

You might like "git pull --rebase"

Don't pull origin/master directly into local feature/test branch. Pull into local master then rebase local branch onto it.

This goes against all the advice I've seen elsewhere; we push our feature branches all the time, and sometimes pull from each other's if we're working in overlapping areas, so we need to not rebase them.

If that's what you want to do, that is fine, but you are no longer using a centralized process if you do it that way.

Git allows you to follow a centralized process perfectly fine. However if you choose to not follow a centralized process, it will not force you to.

Is there a reason you aren't using disposable feature branches?

I don't track my other developers' feature branches locally unless I need to view them.

You're right, thinking about it - most of the time I wouldn't have a copy of my coworker's branch (though we do sometimes pull changes from each other's feature branches - indeed that's supposed to be the big advantage of git, no?)

> It turns out however that Git is really easy to grasp.

Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.

Since you have already read ten things about it and don't understand it, it would help if you told us what you do not understand so that we do not waste our time rehashing things that you have already not understood.

That's a very good question. I hadn't really tried to pinpoint what exactly I don't understand about it until now, but here's what some thinking uncovered:

Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can revert my latest commit.

Another thing I have trouble with is obscure failures. Obviously this isn't something I can just learn, but there are times when git fails for a reason I don't understand...

Ah yeah. The "why" with a lot of the porcelain stuff probably tends to be an unsatisfying "Because somebody didn't think it through very much a few years ago." git-reset would probably be better if it defaulted to --soft, and possibly left the other options to other commands.

Same here, whenever I attempt to give it another chance, sooner or later I break down and revert to hg-git. I recently discovered EasyGit [1] and it seems promising from the docs. There's also gitless [2] that was covered in HN a few days ago.

[1] https://people.gnome.org/~newren/eg/

[2] http://people.csail.mit.edu/sperezde/gitless/

Here http://www.sbf5.com/~cduan/technical/git/ this is the only way to understand git.

That's a great explanation, thank you!

And we all know what runs through porcelain before it runs through plumbing.

1. Linux

2. GitHub

That's it really.

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different).

Vim did win the war; there's still nothing better.

IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that.

Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous.

I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.

> Vim did win the war; there's still nothing better

I'll just put this here for you:

https://code.google.com/p/vim/source/browse/src/eval.c

Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways.

> (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last).

Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.

Making predictions isn't allowed on the internet anymore?

Of course it's allowed. So is judging someone's credibility based on the predictions he chooses to make, whether by the accuracy of said predictions over time, or the plausibility of said predictions in advance of proof's arrival.

Say what you like about Emacs; its source, both in C and in Emacs Lisp, is generally quite readable, and the former I've found to be especially well commented.

> Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means.

Winning means the user experience, not the code. And sure, I was lazy, it would be more accurate to say vim and emacs won between them (and are still fighting it out).

> Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here.

Do you disagree that a) Objective-C was more or less dead prior to the release of iOS b) almost all people currently using Objective-C are doing so solely because it's the language you can write iOS apps in c) absent huge, radical changes, Objective-C will never threaten Java's popularity the way that post-Java languages (C#, GHC Haskell (very different from the language that was standardized in 1990), Go, Scala) are?

No Objective-C was not dead before iOS. A thriving Apple was supporting Objective-C in every way possible, and moving from Carbon to Cocoa.

Objective-C is used to build applications for Apple software. It's not a threat to Java, but that doesn't mean Objective-C is dead. Objective-C will be around for a long time to come. It's a modern language that powers all of Apple's most recent technology. They have no reasons to change, and there are no signs that Apple is on the verge of disappearing into the aether.

Vim is shitty software. I like the UI, but the thing is single threaded and everything runs on the UI thread. There's no hope for async, or an event loop, or even a settimeout like feature. The code is full of globals and trying to add new features to the thing is going to result in inexplicable, unfathomable seg faults. Vim uses shitty regular expressions in the UI thread to do syntax highlighting which is why that's slow for big files and why the syntax highlighting breaks.

So the code matters. There will never be powerful IDE like features as long it's this single threaded thing that only ever does anything as a response to user input. Given the state of the code, changing this does not seem ever possible.

> So the code matters. There will never be powerful IDE like features as long it's this single threaded thing that only ever does anything as a response to user input.

Run VIM in a sub-process, and communicate with it through a fake terminal. Basically, quarantine the madness.

> Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different).

The "GNU/Linux" vs "Linux" discussion is a long one but I'm pretty sure there's (almost?) no GNU in Android.

There's GNU in android.

I don't think there is. What are you thinking of? All of userland is not GPL licensed, I don;t even think any is LGPL, so I don;t think there is any GNU there.

In fsf writing about it:

  Android is very different from the GNU/Linux operating system
  because it contains very little of GNU. Indeed, just about
  the only component in common between Android and 
  GNU/Linux is Linux, the kernel.

http://www.gnu.org/philosophy/android-and-users-freedom.en.h...

I don't normally say "GNU/Linux", but I felt this was a case where the distinction is particularly important, because Android does run the Linux kernel, but is (IMO) a different OS from GNU/Linux.

Right. The reason I made my comment was because you said "which while built of GNU/Linux pieces" referring to Android, which doesn't make sense.

> Vim did win the war; there's still nothing better.

GNU Emacs is much better. It's easier to use and easier to extend.

> Vim did win the war; there's still nothing better

Least substantiated claim of 2014 so far.

Haha, but the race is long :)

>Vim did win the war; there's still nothing better.

Haha, good one. Many of vim's predecessors are better even, nvi is far nicer to use than vim is for example.

> Java did win the war... ...You could argue that Ruby has overtaken it

For what? A specific niche of web applications?

As far as I can tell, Mercurial is being actively developed (i.e., updates being pushed out on a roughly monthly basis), and it's also actively being used. It isn't used as much in the open source community (probably the GitHub effect), but that doesn't mean it's "not looking real healthy" (anymore than OS X does compared to Windows).

Bazaar is a different story. Technically speaking, Bazaar isn't going away anytime soon. Canonical's development depends too much on it. The primary problem with Bazaar is that updates on Canonical's side are pretty much limited to dealing with issues that Canonical has, and there is little activity with respect to getting other bugs/issues fixed/addressed.

This is unfortunate, because Bazaar does do a few things better than either Git or Mercurial.

Yes, Mercurial is being actively developed; Facebook has a great post about why Mercurial and not Git with data: https://code.facebook.com/posts/218678814984400/scaling-merc...

Yes, there are plenty of local maxima, but this is a pretty nice look at the global picture - http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/ - and git definitely won the mindshare war by those numbers.

Bitbucket is nice. I use bitbucket for all of my private git repos, while using github for all of my public repos (and three or four private repos).

Bitbucket provides a good service.

I used Mercurial with a hg-git plugin back in the day as we were a Mac-only shop and I was the only schlub with a Windows machine (I was in charge of fixing IE issues). Mercurial was very good back then, when Git performance was subpar on Windows.

Git on Windows is now blazing fast enough that msysgit will get you by. I still favor the Git workflow even when I am using other SCMs (like right now, where we have a Subversion dependency)

Yes, Mercurial is looking quite healthy—Facebook details why Git doesn't work for them and all of the improvements they've made to Mercurial for their repo which is several times the size of the Linux kernel: https://code.facebook.com/posts/218678814984400/scaling-merc...

Reply on news.ycombinator.com