Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

Post reply on HN
Print view View original

81–90 of 165 posts

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

#81

Post by zeveb »

theandrewbailey wrote: post #28
zeveb wrote: post #12

Earlier quoted context omitted.

> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…

> Ouch, yet another way in which running on Windows can lead to poor technical decisions. I've never heard from anyone that choosing/using Mercurial was a poor decision. Are you biased?

> I've never heard from anyone that choosing/using Mercurial was a poor decision.

I liked hg too, but as the passage of time has indicated choosing it for one's project would have been a mistake, as git has effectively won.

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

#82

Post by blakeyrat »

nailer wrote: post #60
ska wrote: 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,…

How about "git, but actually usable".

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

#83

Post by nailer »

DannyBee wrote: post #78
nailer wrote: 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,…

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

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

#84

Post by dochtman »

I was a Mercurial crew member for a few years (2008 to I don't know) and was very happy to be able to learn from Matt in his role as BDFL. His principled stance against layering violations and his policy to require really small commits still influence my coding every day. I hope he finds something new to give him satisfaction/joy!

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

#85

Post by krupan »

JoshTriplett wrote: post #77
krupan wrote: post #57

Earlier quoted context omitted.

"I find [the index] a critical part of git's culture of making small commits with one logical change each." I've never understood why the index has to be forced on everyone for every commit. Apparently it's due to a belief that everyone always just munges a bunch of changes together in their working copy in a mad coding frenzy and then later realize they need to filter and separate those changes into separate commits…

> "I find [the index] a critical part of git's culture of making small commits with one logical change each." > I've never understood why the index has to be forced on everyone for every commit. You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index. Understandi…

"Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree."

Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.

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

#86

Post by knz »

School-Cotton wrote: post #73
nailer wrote: post #62

Earlier quoted context omitted.

There are tons of companies using Lotus Notes. git won.

What does "won" mean, concretely? I mean, if 75% of people use git and 25% use mercurial, what does it matter? Also it's not true that a lot of forward-thinking, progressive, thought leader tech companies are using Lotus Notes. That is true of mercurial.

I think "won" means that when you are making an argument to introduce a piece of software into your workplace there is a technology that is more widely used. It doesn't necessarily mean that one is better, but there is usually a reason a technology is widely adopted. If you don't fully understand the advantages and disadvantages of similar products then widespread adoption can help with the decision.

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

#87

Post by profeta »

stonogo wrote: post #47
roddds wrote: post #42

Earlier quoted context omitted.

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

Usage without a PhD in git-manpage-generator, primarily.

love to have someone with a PhD in git show how to do the `hg wip` from jordigh above.

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

#88

Post by mrighele »

pekk wrote: post #63
mrighele wrote: post #43

Earlier quoted context omitted.

> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the file…

Have you used both? You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.

Thanks for clarifying, my experience with Git is much more limited than with Mercurial, so it wasn't clear to me that the index is a sort of editable (or partial?) commit (of course now it looks quite obvious).

I understand the appeal of that, in fact Mercurial acquired similar capabilities during it's evolution, thanks to a number of extensions (for example histedit [1])

[1] https://www.mercurial-scm.org/wiki/HisteditExtension

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

#89

Post by kevin_thibedeau »

ufo wrote: post #40
rjbwork wrote: post #20

Earlier quoted context omitted.

TBH, I prefer Hg regardless. I only use git when forced to to interact with a project on GitHub. As for replacement, I don't think anyone wants that. Two widely used open source DVCSes is a great thing.

Have you ever tried out hg-git? It lets you interact with github repos using mercurial.

I've tried it during the transition from Google Code. It works well enough but it didn't handle orphaned branches (as used by Github pages) well and I had to provide credentials twice for every push for some reason.

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

#90

Post by rbehrends »

JoshTriplett wrote: post #6
jordigh wrote: post #3

Earlier quoted context omitted.

Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actual…

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

A couple of technical notes:

> such as a repository structure optimized for performance

Actually, repository structure hasn't fundamentally changed (unless you count the RevlogNG change in 0.9). There have been changes so that data on disk compresses better (the generaldelta change) and there's more underway to support new features (such as narrow clones), but they generally aren't performance-related.

I note that this is a good thing: Mercurial's repository structure allows it to do things that aren't easy for Git, especially efficient random access to history (Git's structures are generally optimized for access close to HEAD and the root of the directory tree), at the expense of requiring more disk space.

The performance improvements you've seen most likely come from more/better caching or reimplementation of time-critical code.

> fast branches without making a separate working directory for each

That was always possible. Documentation (such as the Mercurial book) suggested a clone-based workflow for reasons of convenience and because that's what people were used to at the time, not because you had to do it this way.

Post reply on HN