Hacker News Reader

Comment by wirrbel | Hacker News Reader

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow.

Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just cant wrap my head around (granted I only use it occasionally).

As a platform I like how all the porcellain in mercurial is implemented in a high level python. I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

View on HN

There are two things people mean when they say Git is complicated.

Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model.

What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply objectively correct. For example, "git checkout foo" might mean go to the foo branch, or might mean revert a file called "foo". There is no way to know. If you want to be sure to revert a file called foo, you can do "git checkout -- foo", I believe, but I don't know a branch equivalent (and it at any rate won't be symmetrical). Want to create a new branch? That's "git checkout -b newbranch". Want to delete it? That's "git branch -d newbranch". There are tons of things like this in the Git UI, where commands have basically arbitrary parameters in different contexts.

Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. I really, profoundly wish that had actually panned out. Instead, Git's low-level commands gradually grew more user-friendly until it hit the "good enough" zone. That's what people usually mean when they say Git's complicated.

I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch.

Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is that in one case the current working branch stays the same and in one case it changes (or you could look at it as in one case you set it to the current value and in the other you set it to something different).

This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model.

Also, want to create a branch? "git branch new-branch". Delete it "git branch -d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is an optimization of "find x | xargs rm" (why do two commands when you can do one?).

The only thing I don't like about git UI is that it can't decide what to call the "index". It's called "index", "staging area", and "cache" in various places (including command line flags), which is confusing.

> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model.

Making people understand the internal data structures in order to understand a UI is... not good.

It's not 'internal'. It's the model it presents to the user. Internal would be needing to know how the blob file format works.

See, but I don't think they're "internal" at all.

The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.

> The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.

Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward, backward, parking etc and that's what most car drivers care about.

It's not all that helpful to compare version control tools with cars, I don't think. Users of a version control tool do need to know about branches, tags, commits and such because they are the heart of what version control is. If you've ever seen an environment where version control tooling has been introduced without the support of the developers you'll have seen what happens when you treat it like a car: empty check in messages, commits getting clobbered by "I'll jut check in my version" merges, and contention over file locks in tools where locking was part of the model.

You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels.

Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.

> Git is like driving a manual transmission.

Git is nothing like driving manual.

> In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general.

No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "go slower", and the clutch is for "change gear". People learn to do it right because the alternative is to stall or get a horrible grinding sound and pay top bucks to get stuff fixed, not because they understand how things work under the hood.

[0] in countries where it's the norm, not in countries like the US where manual is for nerds and passioned

> Different gears are for "go faster" and "go slower", and the clutch is for "change gear".

Sorry, that's exactly what I meant by "the different gears work in general". You need to understand that underlying model before you can make it work, even if it's only intuitive, and not cerebral.

> the clutch is for "change gear"

That, and it's also "don't stall when I stop".

I think most people understand that it disconnects the engine. I don't think that's as crazy a leap as "understanding the details of how a gearbox works" (which I don't even know, since I've never looked in one).

Anyway, I maintain that my analogy is apt.

> You need to understand that underlying model before you can make it work

No, you only need to understand what the final effect is. The vast majority of drivers neither understand nor care that gearbox speeds change the conversion ratio between the engine's rotating speed and the axle's, if you did and had to gear speeds would be labelled by their conversion ratio not 1-6 (and then you'd have to include the axle's conversion ratio in the mix). And I don't doubt that a Git-based gearbox would do exactly that, and that going in reverse would require either using an inverter or would require using a completely separate reverse transmission.

> Anyway, I maintain that my analogy is apt.

And I maintain that it is not.

> Do you think that people who drive cars know in detail about how car works?

I think professional drivers do indeed know how their car works. They certainly should.

We are talking about professional developers/programmers/devops here, right?

Do you want to understand exactly how a car works, or do you just want to go places?

The thing I find unpleasant with git is the inconsistency of commands. Why git branch -d for deleting branches, but git remote rm for deleting remotes? Etc.

As to git's basic model - a dag of commits, with branches being little more than auto-updating labels for commits - that fit into place in the first 5 minutes of usage. My learning time with git was shorter than any previous source control I used, except for sourcesafe, in so far as that is a SCM.

Your complaints seem like a very indirect way to get what you want. Perhaps it's git's fault for making these possibilities, but I didn't even know they exist.

If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout.

If you want to create a new branch, why not use "git branch branch-name"? As another said, the "git checkout -b branch-name" is just shorthand for convenience.

I've been learning git over a mere 2 months (I came from svn), I'm finding its UI to be very pleasant.

As someone else said, that index/staging/cached situation is bad, though.

"If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout."

Because that's what git tell you to do when you run "git status"

# (use "git checkout -- <file>..." to discard changes in working directory)

Interesting you should mention "git reset", because, depending on the options you give it, it either:

  * reverts one file
  * reverts all files
  * removes changes from the index, but doesn't otherwise change anything at all
  * moves your branch, without changing any files
  * moves your branch and changes all files

This rather makes my point.

"git checkout -b", meanwhile, is not a shorthand for "git branch something", but rather "git branch --track something origin/something", unless there is no "origin/something", in which case you are again correct.

The branch equivalent is `git checkout foo --`. I wrote a simple shell script[1] that makes that the default, requiring you to do `-- <file>` for files, so there's never a possibility of ambiguity.

[1] https://gist.github.com/russelldavis/e5173ce1269fae67baaf

> "the plan was for what is now called Git to be the underlying implementation of a higher-level UI"

Some time around year 1960, the plan was to develop a language with syntax ("M-expressions") on top of the Lisp S-expressions.

We are still waiting, I guess.

http://www-formal.stanford.edu/jmc/history/lisp/node3.html

Relevant: http://stevelosh.com/blog/2013/04/git-koans/

> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI.

Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?

http://en.wikipedia.org/wiki/Cogito_(software)

EasyGit, and others: https://people.gnome.org/~newren/eg/

> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git.

The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes.

There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)

I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.).

Any first hand experiences with this?

Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers:

http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py

> Git is intuitive with a small number of concepts necessarry to grasp my whole workflow.

http://jordi.inversethought.com/blog/on-gitology/ explains git's complexity extremely well (without even getting into horribleness of the command line UI). The following is a key quote, though you should read the whole thing.

The following gitological concepts are not particular to git:

* repositories (repos)

* commits or changesets (csets)

* directed acyclic graph (DAG)

* branches

* pushing and pulling changes

* whole-repo tracking, not individual files

* rebasing csets

* pushing and pulling csets

The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable:

* Exposing the index/staging area

* Exposing other implementation details: blobs, trees, commits, refs

* refs and refspecs

* Branches are refs

* Detached HEADs (a.k.a “not on a branch”)

* Distinguishing remote and local tracking branches

* Choosing which branch to pull onto

* Bare repos

* Hard, soft, mixed resets

* Porcelain vs plumbing

As with most software, it probably depends largely on what you're used to. I started my distributed SCM life in Mercurial (moving from svn) and found it to be fast, simple and friendly to use. Being an experienced Mercurial user, I hated git when I first started using it - changing something as core to one's development life as the SCM isn't easy.

But after a while of working with both, you start seeing git and hg as relatively equal products, just with different UI quirks.

I eventually moved most of my projects to git, though. Not because I thought it was better, but because it was more widely used. And being the collaborative type, using git was the path of least resistance.

Kind of sad how this post seemd to have resonated mostly for its reference to git, I intended (and failed) to point out my questions on mercurial. As a git user, I see one of the main features for mercurial: As it is in python, it can be used as a library. This should make tooling and cool developments so much easier for the average developer who is not a shell script person.

The key concept that you need to truly understand how Git works is to just remember that Git is just a tree of commits, with temporary and movable Post-it notes attached. (The Post-it notes representing branches and other references).

That's a good image. The key difference to Mercurial is then that Mercurial's tree of commits don't need Post-it notes. The tree can stand on its own without extra branch labels. You can add them (see bookmarks) but they're an optional feature.

Reply on news.ycombinator.com