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

191–200 of 263 posts

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

#191

Post by gora_mohanty »

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…

Heh! Are you me?

Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.

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

#192

Post by bsder »

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…

> Well I can explain git to anybody who understands a DAG.

This. Right here. This is the difference.

I can explain Mercurial to people who don't want to understand a DAG.

For non-professional developers, the "merge machinery" is completely worthless.

The difference is that Mercurial lets you duck it until you need it while Git slaps you in the face with it at every commit.

For the non-professional developer, the flow is "commit, commit, commit, commit, whoops--how many commits do I need to go back to fix things?, oh, 2, okay--revert, commit, commit, commit, commit, ...

At no point in their day are they facing "merge". And that makes all the difference.

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

#193

Post by kaeshiwaza »

j_bum wrote: post #182
ncphillips wrote: post #51

Earlier quoted context omitted.

I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it

Would you be willing to pitch why you like jj and find it useful? How were you using git? I use git mostly on single-dev projects, with branched development patterns. Would someone like me with a simple git use-case find JJ enjoyable?

jj is amazing, even as a solo dev on small projects. It's difficult to explain because it depends of each usage, but it's very easy and safe (you can undo everything) to just try and see.

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

#194

Post by qsera »

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…

People make this claim but it never made sense to me. How do you know the version that you are committing is buildable if you never tried building with it? And if you tried building with it, you can just do `git add .` or `git add -u` at that point.

So yes, your usecase does not make sense to me.

There was another comment that said similar thing...

https://news.ycombinator.com/item?id=48175289

>So you're just constantly committing untested versions of you work?

But it is "dead" for some reason...

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

#195

Post by happymellon »

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…

> Git I can barely even explain to CS majors.

Considering the number of kids that I've managed to understand git, I think this might be a teaching issue.

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

#196

Post by ezst »

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…

Then you made the right choice, and it's only unfortunate that not enough of you made the same to tip the scales in favour of mercurial, or at least to avoid the monopolistic situation we are in now.

I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.

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

#197

Post by Mashimo »

didibus wrote: post #181
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 often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.

You could also commit, and then squash the pull request.

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

#198

Post by tekacs »

bsder wrote: post #188
tekacs wrote: post #156

Earlier quoted context omitted.

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

I'm already a quite happy jj user, but thanks for the recommendation. :)

Glad to hear it :)

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

#199

Post by spit2wind »

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.

If you're talking about binary files, then it has similar limitations to Git and Mercurial, AFAIK. Fossil, git, and Mercurial are not really designed for large binary files.

Otherwise, in Fossil, any text is just another artifact. Wiki pages can be stored as files in the repo ("embedded") and versioned in the same manner as code files (that is, exposed through the same interface), or tracked behind the scenes (in a separate database, IIUC, with a different interface). Tickets and forum entries are also tracked and versioned similarly to non-embedded docs.

Aside from everything being versioned, the visibility of the objects is quite good. The user interface, both command and web, is light-years better than anything Git related.

I highly recommend you check it out. Even if you find it doesn't meet your needs, many of the design decisions are instructive. I find it quite inspiring.

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

#200

Post by Mashimo »

kccqzy wrote: post #102
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’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto). In contrast every single mercurial user I know can intuitively use `hg rebase…

Is that a common usecase?

I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.

Post reply on HN