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

151–160 of 165 posts

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

#151

Post by masklinn »

Myrmornis wrote: post #148
masklinn wrote: post #26

Earlier quoted context omitted.

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?

> Is the revset feature basically a DSL for specifying queries

Yes, it's a way to select sets of revisions by filtering and merging existing sets.

> and are the queries thus-specified ones that have direct analogs in git and can be done in git using git's API?

I don't think so, not all of the filter operations are available, but more importantly I don't think git supports arbitrary sets of revisions, only fairly basic relatively continuous ranges (that's the idea I get from gitrevisions(7) anyway)

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

#152

Post by rockdoe »

amadvance wrote: post #21
School-Cotton wrote: post #16

Earlier quoted context omitted.

There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.

I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.

I'm not sure. I have the impression some larger organizations that are moving or using monolithic repos are now aligning more strongly towards hg, because it's easier to extend and optimize than Git.

If you look at the outside contributions that both projects get, this is pretty obvious. Hg is getting big changes from Facebook, Google, Mozilla, ...

Maybe the answer to the argument that a paradigm change is needed to unsettle git is simply "monolithic repos".

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

#153

Post by bsder »

starseeker wrote: post #122
Karunamon wrote: post #120

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.

That's actually quite interesting - I remember similar comments (Phd required, or Phds aren't able to understand it) cropping up in discussions of the GNU autotools toolchain. (With a fair bit if justification, in my own experience, although I understand the results tended to be better for those who were shell script gurus...)

Autotools is actually quite simple to understand.

If your install needs autotools, your install is broken. :)

The number of projects that need autotools in this day and age is vanishingly small. A small script (bash/python/perl/ruby) that checks exactly what you need and then runs make instead of copying 15 years of cargo cult m4 is far superior to autotools.

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

#154

Post by bsder »

acveilleux wrote: post #118
bsder wrote: post #111

Earlier quoted context omitted.

> but on the availability of programmers who know how to use it The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it. Relevant xkcd: https://xkcd.com/1597/

It gets much worse once you step out of the open source software and start up communities.

This is exactly what keeps me on Mercurial.

I can teach Mercurial to CEO's, artists, students, etc. and some of them will be better than me on it with a week or two. All of them "get it" and it's "low friction"--they can commit and forget about it. People who need it can handle merging and the rest can ignore it. People who need branches can use it and the rest can ignore it. etc.

git doesn't allow this. git is all or nothing. Either you inload the whole mental model, or you WILL wedge your repository somehow when you execute a command that doesn't quite do what you think it does. At that point, you will spend 4 hours combing Stack Overflow for the answer. Or you will just pull up the filesystem copy of the git repo you made before executing any command other than "git pull" or "git clone".

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

#155

Post by lsaferite »

theandrewbailey wrote: post #114
zeveb wrote: post #81

Earlier quoted context omitted.

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

You haven't mentioned why you think Git won. If by "won", you mean "is more popular", then yes, it won. But that criteria alone doesn't make a decision bad. When changing gives you no clear advantage, why change to something more popular?

Isn't that akin to arguing that choosing to distribute your movies only on Betamax is not a bad decision?

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

#156

Post by jordigh »

scrollaway wrote: post #131
krupan wrote: post #85

Earlier quoted context omitted.

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

Having used both git and mercurial extensively I can guarantee you the index is not a needless complication, it is a feature sorely missed in hg.

With `hg commit --interactive` and `hg amend --interactive`, I really don't see what's the difference between a temporary commit that you keep adding stuff to and a staging area. It's all just diffs and hunks. Whether it's finalised or not is just a matter of perspective. Mercurial encodes this perspective by distinguishing draft from published commits.

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

#157

Post by ska »

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

   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.

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

#158

Post by 16bytes »

olau wrote: post #113
carussell wrote: post #93

Earlier quoted context omitted.

Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010. Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot". Coming from a Mozilla-influenced, pre-GitHub-exp…

Mercurial has some warts of it own. Common case of working on something, then wanting to update the repository in the midst of it to get something from a co-worker isn't handled exactly stellar. So you can shelve. When you have enabled the extension. If I'm not mistaken, even CVS handled this better.

> hg clone . ../CloneForCoworkerInvestigation

This is way, way better than CVS. Some people complain about how this doesn't work in place, like git or shelve, but I prefer I don't have to change anything in my main repo, like regenerate IDE files, dependency caches etc.

In any event, I've always like how this worked.

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

#159

Post by alblue »

gnuvince wrote: post #51
IshKebab wrote: post #29

Earlier quoted context omitted.

Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.

Or if Github had added Mercurial support at the same time Bitbucket added Git support (circa 2011?), I do believe that the playing field would be a lot more even today than it actually is.

Mercurial's storage format was broken from birth; it dealt with the concepts of individual files and history on them. Git's storage format was much more basic but more flexible, with the result that it was possible to implement the Git storage engine in different languages (cgit, jgit, libgit) as well as a minimal transfer protocol.

http://alblue.bandlem.com/2011/03/mercurial-and-git-technica...

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

#160

Post by Karunamon »

exDM69 wrote: post #138
Karunamon wrote: post #120

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.

Ridiculous, as in, a case where we actually need it is rare enough that by the time the need arises, everyone's forgotten how it works.

We're not in a shop where one-off merge commits are a thing anyone really cares about, so rebases usually mean things like "Somebody used the wrong committer name" or "Somebody did a branch merge incorrectly and now the history makes no sense".

The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

(1): The, IMO, canonical example for awful documentation design - why does a user credential switching program open with a primer to EBNF when it's hardly necessary?

Post reply on HN