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

151–160 of 263 posts

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

#151

Post by squirrellous »

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…

Both Facebook and Google internally use a custom version of mercurial, so I wouldn’t count it out just yet.

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

#152

Post by dwattttt »

anal_reactor wrote: post #135
kccqzy wrote: post #104

Earlier quoted context omitted.

> history is a stream of content-addressed commits Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`. Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stab…

You mean "git tag"?

If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git.

EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy.

A git-native workflow for this would be to have a sequence of branches you continue to update, where 'main' is those branches merged at all times.

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

#153

Post by streetfighter64 »

bsder wrote: post #139
streetfighter64 wrote: post #126

Earlier quoted context omitted.

> The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it. I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)? About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer fr…

> 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 data structures. Had mercurial won you'd see exactly the same types of errors commonly appearing.

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

#154

Post by JuniperMesos »

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 find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.

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

#155

Post by spacechild1 »

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…

> 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 exception?

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

#156

Post by tekacs »

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…

https://github.com/jj-vcs/jj

On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ.

I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize).

It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time.

Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).

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

#157

Post by jdiff »

kccqzy wrote: post #104
loeg wrote: post #82

Earlier quoted context omitted.

> How do you consider the UX "nearly identical" or "arguably worse"? The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better. > hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. hg histedit is basically identical to git rebase -i. The names are diffe…

> history is a stream of content-addressed commits Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`. Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stab…

Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.

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

#158

Post by interroboink »

irishcoffee wrote: post #146
ciupicri wrote: post #80

Earlier quoted context omitted.

I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.

What does short lives branches even mean? Make a branch, close it, or merge it.

Short-lived branches are likely referring to "bookmarks" in Mercurial. Or they could also just be un-named anonymous heads. These are different from what is exposed by the "hg branch" command.

Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.

The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.

This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.

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

#159

Post by tacticus »

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…

Mercurials lack of not permanent branches early on with the bizarre "we have a plugin for that" way of doing it showing up too late to change the decision

not to mention the early "just clone it into a new dir" answer before lightweight branching ...

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

#160

Post by tacticus »

rileymat2 wrote: post #33
amluto wrote: post #24

Earlier quoted context omitted.

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

I think I liked the Mercurial branching model better than git, due to the branches being a first class record of events. What I did not know is how common the git rebase/clean linear history would become or a desire to change history on merge. Mercurial had bookmarks that were roughly the same as git branches. The linear version numbers were quite useful to reason about and use in places that call for a "number" vers…

shame it took years to get bookmarks in.
Post reply on HN