Hacker News new | ask | show | jobs
by streetfighter64 27 days ago
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.

3 comments

Mercurial doesn't require understanding a DAG.

You can get by with `hg next`, `hg prev`, and `hg rebase -s <from> -d <to>` 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...

Look, I'm not commenting on which system has better named commands. My main points are

1) A DAG is not a difficult concept to understand (despite the "scary" name). If you can understand package dependencies or a manufacturing process you already understand it.

2) Learning git without knowing about the DAG, i.e. knowing what a commit even is, is counterproductive. It's like learning to drive a manual car without knowing what the clutch does. Sure you could probably teach someone that way, but why would you? What's the benefit to learning mercurial without understanding what a rebase actually does?

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

The non-professional flow you described does not require merging in git either. I suppose most teaching resources about git go deep into merging because it was created for distributed development where that's important, but it doesn't mean you have to teach it to a non-professional like that.

Not that I think mercurial didn't have "simpler" UI back then, but the arguments thrown around in this thread are pretty bollocks.