Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Except unlike your examples, hg was contemporaneous with git.

Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.



Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm.

rcs: revision control

cvs: concurrent check outs

svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this)

git: decentralised version control

To replace git, you need a new paradigm. I don't know what it is, and I think few people here would.

Edit: to reiterate, none of this has anything to do with whether git or hg is technically better.


Except its not the DCS paradigm that led to git's network effect. In fact, for the vast majority of users they are using it as a de-facto centralized system (on github).

DCS was around before git and did not sweep the tech industry. Just like concurrent check outs weren't the reason cvs took off.


>To replace git, you need a new paradigm. I don't know what it is, and I think few people here would

um.... how about a good command-line UI that doesn't require remembering all sorts of crazy command line switches?


Most would agree that Git's command line leaves a lot of room for improvement (although the manpages are quite good at explaining). But the internal concept is sound.

I find it a bit odd that no-one has come up with a decent GUI or an improved command line tool for Git yet. There's plenty of attempts to supplement Git with extra commands but that's hardly an improvement. There are several implementations of the Git plumbing parts (e.g. libgit2), so making an UI on top of it wouldn't be that much work.


"svn: renames that aren't awful and keep history "

No, it was "atomic commits and single revision number for a change"

Remember CVS had non-atomic commits (part of the commit could succeed, part could fail), and per-file version numbers.

Disclaimer: I worked a lot on SVN :)


I stand corrected. Will edit my post and credit you.


Git was far from the first DVCS though, or even the first open source DVCS. Darcs, Arch, Monotone at least came before. So this does not explain why Git is the most popular DVCS, or why Git is more popular than Mercurial.


   Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm.
No, it really isn't the point. How can hg "replace" git, when they were be developed at roughly the same time for roughly the same purpose (replace bitkeeper, provide a DCS for open source work), with roughly the same model.

Git didn't come up with the paradigm, and neither did hg.

git and hg were direct competitors, not different generations of revision control like the list given.


I think the big big points for git initially actually were: 1) performance - everything comparable but open was way slower back then 2) a usable and relatively small per-checkout history

In the cvs & svn days I used a fair amount of hacks to get those two, and pretty much always failed. For svn svk was a partial solution. For cvs there was rsync, but also something else I can't even remember. Bad memories fade.


svn eventually got a fairly hacky answer to merging edits to a renamed file. For a long time it didn't even try, and git was a godsend compared to straightening out messes like that.


How about "git, but actually usable".


Thats mercurial :(




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: