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

181–190 of 263 posts

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

#181

Post by didibus »

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

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

#182

Post by j_bum »

ncphillips wrote: post #51
yegle wrote: post #47

Earlier quoted context omitted.

I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub. Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.

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?

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

#184

Post by Tor3 »

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…

Same. I absolutely don't use git for snapshotting what I'm currently doing. That goes both for work and for my numerous hobby projects. I always cultivate commits so that they're focused on a single type of change or feature, and then the next commit is typically something which uses that feature, etc. I don't mix in whatever else I'm doing - be that whitespace changes, update comments elsewhere, or other features I'm working on. This helps tremendously when (as I do) I leave my hobby project for a while and then I come back months (or sometimes years) later. And, both for work and for hobby stuff, if I want to add something, e.g. support for a new function, and I had done something similar in the past, it's easy to look at the particular commits about that from the past, and I can see that I need to update this, this, and this file so-and-so, and with these kind of changes. I don't have to wonder about what belongs to this feature and what doesn't.

Oh, and I use git add ---patch almost exclusively. It's rare that I just do a "git add". I'm building up my stage, I'm checking it, I'm fixing it (if I accidentally stage something which doesn't belong), then I commit.

Having done it like this for a great many years I'm benefitting from it all the time. I can look at all my hobby projects (looking at the commits), and I'm back in where I left off, and I see excactly what I was doing back then (which, obviously, I wouldn't be able to rembember otherwise).

CVS though.. that was harder to do right. So a lot of stuff became just snapshots. You had to plan much more carefully. And then there was SCCS before that.. and before that again, well. Manual "keep two versions" svc.

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

#185

Post by Tor3 »

com2kid wrote: post #178
streetfighter64 wrote: post #153

Earlier quoted context omitted.

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…

If I spend a couple hours reading I can understand how git works, but I'm going to forget an hour later because it is so damn complicated with all the different details that my brain flushes it's cache to make room for something with less violently confusing edge cases.

For understanding git internals I went through "Git from the bottom up", a simple document with examples you type in, just to see what's going on. Many of those examples are raw git commands, nothing as sophisticated as "git commit". Easy to read, doesn't take long, but leaves behind an understanding that isn't maybe fully obvious at the time but makes everything much easier, forever. I've recommended that method to many coworkers and it seems to work well for most people. It doesn't need hours of reading either.

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

#186

Post by unnah »

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 don't see why there has to be a special staging area when you could just edit the HEAD commit instead. In git you could do "git commit --patch" to commit selected parts and then add more changes to the HEAD commit by "git commit --patch --amend".

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

#187

Post by HWR_14 »

martin-t wrote: post #60
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…

I hate that social factors like popularity are a thing in technical decisions. I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortun…

> Tragedy of the commons

That's a different concept. You are describing network effects.

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

#188

Post by bsder »

tekacs wrote: post #156
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…

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

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

#189

Post by loeg »

Arainach wrote: post #172
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…

git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time. hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions. The two are as "equivalent" as i3 and KDE.

I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.

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

#190

Post by loeg »

Arainach wrote: post #169
streetfighter64 wrote: post #153

Earlier quoted context omitted.

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 `c…

I disagree that Mercurial users can use `hg rebase -s ... -d ...` without understanding a DAG. The mechanism is only meaningful if you understand the structure of the commit graph.
Post reply on HN