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

131–140 of 263 posts

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

#131

Post by BeetleB »

bluGill wrote: post #103
BeetleB wrote: post #88

Earlier quoted context omitted.

Yes - whenever I'm in a team and I hear someone who insists on a linear history, I always wonder why they have trouble with merge when lots of folks like me have no problem with it. Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in reb…

Rebase makes sense when you realize git doesn't have branches. Git has tags that move but no branches. That means when you merge you have no clue which branch was the mainline and which was the fork. This is a question I often ask 10 years after switching to git. Sadly git has better tooling so it is worth using despite the issues.

> That means when you merge you have no clue which branch was the mainline and which was the fork.

You mean - when looking at the history?

Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).

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

#132

Post by BeetleB »

justin66 wrote: post #105
BeetleB wrote: post #87

Earlier quoted context omitted.

> The UX is almost the same as git, I've used git and mercurial for roughly the same amount of time. Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.

> I've not used a VCS with a worse UI ...than git? than hg?

Than git.

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

#133

Post by eclipticplane »

tasuki wrote: post #17
juvoly wrote: post #5

Earlier quoted context omitted.

Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted. Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.

> Mercurial wasn't as simple as Subversion. What? Subversion is by far the most complex versioning software I've ever used. > Git has so many gotchas, bells and whistles The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.

Subversion pre-1.5 was a nightmare. Branch merges were by convention in commit messages. To merge 20 commits from your branch, you would do `svn merge -r 125:140 /branches/my-feature` and then note in the commit message which range you merged.

1.5 made that tracking automatic but just shoved it into a metadata field that just percolated through every directory in a project.

And if someone tried to rename a core path? In the distance, sirens.

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

#134

Post by jamesfinlayson »

Xirdus wrote: post #97
dijit wrote: post #62

Earlier quoted context omitted.

Writing your tooling in python is valid while starting out and prototyping. One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience. I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively. Starting with C was great for performa…

> Starting with C was great for performance of Git Isn't the entire git rebase logic written in Bash scripts? Or was originally?

Possibly? I'm sure I read that the first "release" of git was five barely documented binaries that could be strung together to do version control.

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

#135

Post by anal_reactor »

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…

You mean "git tag"?

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

#137

Post by giraffe_lady »

nsvd2 wrote: post #111
smartmic wrote: post #83

Earlier quoted context omitted.

Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.

I've always been interested in Fossil, especially how they handle all the things in a project that aren't strictly code but still need to be tracked.

I'm like the person you responded to, I've just used fossil personally for years after working at a place using it a while back and always liked it.

This is its moment though. It is so well suited for LLM coding tools. You can jam all the markdown context, skills etc into the wiki. The CLI has wiki and ticket tools so those are just available for it to use. Fossil does not mind if you use the repo DB for your own stuff, so you can log all your sessions in there, fts5 is plenty for as needed on demand retrieval.

Big changes to professional development over the last year and hard to predict how it will all shake out, but I think the tooling will converge on something that fossil already has all the structure for. I was a late adopter on LLM-assisted coding but already feel ahead of a lot of my peers because of how easy and effective this approach is.

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

#138

Post by bsder »

nezi wrote: post #130
jjav wrote: post #52

Earlier quoted context omitted.

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.

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 on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX.

Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.

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

#139

Post by bsder »

streetfighter64 wrote: post #126
Arainach wrote: post #78

Earlier quoted context omitted.

How do you consider the UX "nearly identical" or "arguably worse"? The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, a…

> 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 in particular loved Mercurial as it protected them against changing some wonky setting in their CAD program that screwed everything up that they somehow couldn't figure out how to restore.

Git I can barely even explain to CS majors. The fact that AI has so much training data and is so very, very good at explaining how to undo strange Git states is all the evidence you need for just how abjectly terribly the Git UX is.

Jujutsu has proven that the underlying structure of Git is acceptable and that the issues really are all about the UX.

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

#140

Post by bsder »

t43562 wrote: post #74
loeg wrote: post #56

Earlier quoted context omitted.

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

I thought it was enormously better because it helped you not to cut yourself with all the dangerous things in a way that git didn't. It also had an excellent GUI (thg). It was a much less stressful tool to use and git hasn't really got much better since then - I've just converted a repo to git and the team using it have had about 4 unpleasant mistakes in the last week as they adapt. As for speed.....I cannot say I ev…

If you want to use Git with a sane UI, use Jujutsu. As a Mercurial user, you'll feel a lot more at home.
Post reply on HN