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

Mercurial, 20 years and counting: how are we still alive and kicking? [video]

fosdem.org

Post reply on HN
Print view View original

161–170 of 263 posts

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#161

Post by somewhatgoated »

amluto wrote: post #108
somewhatgoated wrote: post #55

Earlier quoted context omitted.

I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git. What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

“Far better tooling” means that you don’t need to do git help reset and try to remember each of the nonsensical choices, for example.

Gotcha - most people here probably use git for more complex stuff - I almost exclusively use the same 20 commands for my daily work and wrote a cheat sheet for them ages ago (I mostly memorised it by now). Occasionally i need to ask an LLM for some help but that’s maybe once every few months.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#162

Post by BobbyTables2 »

bsder wrote: post #138
nezi wrote: post #130

Earlier quoted context omitted.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

With “git reflog” and “git reset” or “git checkout” one can undo any series of ill conceived squash/rebase/amend operations. There’s actually no need to rsync the work area in advance.

Try doing the same in any other source control system…

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#163

Post by dreamcompiler »

bsder wrote: post #138
nezi wrote: post #130

Earlier quoted context omitted.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point.

Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#164

Post by joombaga »

spacechild1 wrote: post #155
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

I'm with you. My current code is a superset of the task I'm trying to accomplish, test code, leftovers from experiments, etc. I often have to break it up into logical chunks that get merged separately. I tried the jj flow and it's just not my thing. Git matches my mental model exactly, but I used it second (after subversion) and in my most formative years as a developer. Maybe there's a universe out there where things worked out differently.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#165

Post by martinpw »

dreamcompiler wrote: post #163
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point. Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes th…

I've always felt bad about not understanding git better and wanted to dedicate time to learn it properly but never got to it. Finally this is a use case where AI is really good. It has always been able to get me out of trouble when I mess up, and often rescued files I thought I had lost for good. And is always able to rebase for me, normally a place where I flail pathetically. And it's easy to human verify the result before pushing.

Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#166

Post by txhwind »

bsder wrote: post #138
nezi wrote: post #130

Earlier quoted context omitted.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

I'm curious on the use of rsync in version control. What's the source and destination?

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#167

Post by fragmede »

txhwind wrote: post #166
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

I'm curious on the use of rsync in version control. What's the source and destination?

from src/ to src_final_(4)/

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#168

Post by fragmede »

spacechild1 wrote: post #155
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

> Am I the exception?

Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#169

Post by Arainach »

streetfighter64 wrote: post #153
bsder wrote: post #139

Earlier quoted context omitted.

> About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis. Nope. You are simply flat-out wrong. I have taught Mercurial to CEOs, secretaries, artists, craftsmen, etc. It just worked. They understood the mental model and happily used it to protect their stuff. The people I taught Mercurial to who worked with CNC machines…

Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable". The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone da…

Mercurial doesn't require understanding a DAG.

You can get by with `hg next`, `hg prev`, and `hg rebase -s -d ` to move entire chains of commits around. Commands with obvious names that allow moving around without understanding chains of dependencies. No weird states where you checkout an old commit but random files from where you just were are left in the directory tree for you to deal with. No difference between `checkout`, `reset --soft`, and `reset --hard` to remember. No detached head states.

And no, `HEAD~1` is not a replacement for `prev`. One is a shortening of "previous", one requires you to remember a magic constant based on knowledge of the DAG.

As for `hg next`, the various responses here should show how clear, obvious, and intuitive the git UI is: https://stackoverflow.com/questions/6759791/how-do-i-move-fo...

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#170

Post by aidenn0 »

jjav wrote: post #52
PathOfEclipse wrote: post #10

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and pe…

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else. I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

My recollection is that it was more of a VHS vs Betamax story than one being strictly superior. When a lot of people were making their decisions, Git was a lot faster in ways that mattered. IIRC, shortly after a lot of places picked Git, Mercurial cut a release that significantly improved performance.
Post reply on HN