Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

141–150 of 165 posts

Re: I'm going to slowly move on from Mercurial

#141
post #65
post #60

Earlier quoted context omitted.

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,…

>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.

Re: I'm going to slowly move on from Mercurial

#142
post #130

Earlier quoted context omitted.

> but fundamentally you're still installing msys (2) to run git. You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd? Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.

Ever heard of a thing called powershell?

Is that like Bash for Kids?

Re: I'm going to slowly move on from Mercurial

#143

Earlier quoted context omitted.

hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly. Mercurial, in contrast, is "opinionated". (Before you mention github -- the timeline here is also backwards, github became…

I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.

> Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.

Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This is very well explained in the first commit(!) of git, which explains the concepts and the internal database layout.

In Git, there might be a "default workflow" that the tools are geared towards but you can use rebase and cherry-pick and all the other tools to enable just about any workflow you can imagine. Of course, this allows you to turn it into a big mess and there are some weak spots (like tracking a lot of bugfix commits backported to several release branches) but the concept is simple and sound.

Re: I'm going to slowly move on from Mercurial

#144
post #60
post #18

Earlier quoted context omitted.

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,…

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.

Re: I'm going to slowly move on from Mercurial

#145
post #139

Earlier quoted context omitted.

Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome. For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Fa…

> English won English did not won. It might be widely spoken in the 21st century, but so were Greek, Egyptian, Latin, French, Portuguese and Spanish once upon a time. I might be writing this in English now, but saying it won implies no change in common language will ever happen again. Given the history of mankind and some of the countries I had the pleasure to visit on my life so far, I doubt it. Specially since most…

> English did not won.

Apparently not.

Re: I'm going to slowly move on from Mercurial

#146
I think hg was/is important, to provide competition to git.

But I don't really understand all the people arguing that hg is so much easier to use, and so much cleaner. Sure, in the first few years that was true, and there's architecturally better choices (not a mess of scripts, embeddable as library). But from a day to day usage, hg seems worse to me. And that includes the documentation, something that really surprised me after I had to restart using hg a year or so back.

The whole thing how hard it is to actually get rid of branches (no, I do not want to merge that branch. Yes, I don't want any central record anymore. No, I don't want to ssh into the remote box. Uh....), really bugged me. So does the need, slowly abating, to activate a lot of random plugins to get functionality that git had for years (pagers, incremental add, staging area, ...).

But I very well, and I actually mean that, might just be mind warped by having used git so long and so continually that I just don't see the problems anymore and it just seems easier. I do remember some initial difficulties understanding it, but that was in the quite early days...

Re: I'm going to slowly move on from Mercurial

#147
post #138

Earlier quoted context omitted.

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

> The moment something ridiculous needs to be done like a rebase Rebase, "ridiculous"? Uh oh. It's a very valuable tool and it's a quite simple concept. I agree that the user interface could be less confusing, though. Git is just a malleable graph made out of patches. The concept is really simple (even simpler than hg). The UI could be better but the manpages are rather good at explaining how it works.

Just because something is conceptually simple does not make it simple to use. Similarly pointers are simple. They are things (usually variables) used to point to other things in memory by storing the memory address of the target. They are simple. And yet their usage is very complex.

Re: I'm going to slowly move on from Mercurial

#148

Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

How much of the hg revset functionality could be implemented for git, without writing any C? Is the revset feature basically a DSL for specifying queries, and are the queries thus-specified ones that have direct analogs in git and can be done in git using git's API?

Re: I'm going to slowly move on from Mercurial

#149
post #143

Earlier quoted context omitted.

I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.

> Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow. Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This…

This. Absolutely this.

It's ironic how many people claim that Mercurial is simpler, when actually git is much simpler and more elegant. You don't need named branches, bookmarks, extensions, and all that stuff. Just a graph of commits. The core of git is beautifully simple.

I don't know what's more frustrating-- people who think DVCSes need to be really really complicated, or people who endlessly complain over what color the command-line bikeshed is painted.

Re: I'm going to slowly move on from Mercurial

#150
post #60
post #18

Earlier quoted context omitted.

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,…

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.
Post reply on HN