Hacker News Reader

If git exposed a consistent, understandable interface to its data model you'd have a point.

Mercurial exposes a much more consistent, much more understandable interface to a very-similar-to-git data model, so it's not like this is impossible.

So it'd be really nice if people could be allowed to point out the shortcomings of git's command-line interface without other people implying their complaints must be rooted in being too dumb and/or too lazy to understand git.

Having never used mercurial. What are some of the places where mercurial provides a better interface than git?

Just read this: http://stevelosh.com/blog/2013/04/git-koans/

And then think about that Mercurial simply makes handling branches/updates/resets in a very clean and consistent way.

Clearly not a new post, but the first time I had seen it, clearly spells out what has frustrated me (and many others) for a very long time.

You really should warn us not to drink anything while reading that. I almost spit my drink over the keyboard laughing at this

The basic mercurial command set is directly descended from the time-tested cvs and svn commands. Significantly different tasks are executed with distinct commands. In contrast, git dispatches to a subprogram with the top-level command, and then also gets the subprogram to execute different distinguished tasks with its arguments. Its a rather leaky abstraction that pollutes the command syntax.

But since I've said something disparaging about git, I want to balance it out with something nice about it. Git handles remote tracking branches much more nicely than mercurial. For a while I found myself in a mode where I did most of my work on my workstation, saved to a central repository for collaboration, and took a laptop into the lab/field (I'm an embedded developer). Git trivially allows me to handle multiple remotes from the laptop, with one remote referring to the desktop and one referring to the central repository. Since git lays down distinguished branch names automatically for all of (in mercurial terminology) the remote heads, its easy to diff/merge between them as appropriate when I'm in the field. In Hg, its impossible as far as I know. I had to set up multiple clones to track the two.

See my other replies below. I can't edit my above post now, but I'd like to make clear that I wasn't disagreeing that git(1) has a horrible, obtuse interface.

When I say to "meet Git where it lives", I mean "ignore git(1) and focus on the merkle-tree datastore it creates." That datastore (to really stretch the analogy) is a toothbrush-head with rather excellent bristles. Used correctly, it can get your teeth very clean. git(1), on the other hand, is a horrible, obtuse handle attached to it. Ignore the handle; focus on the bristles.

(What this statement really means, to me personally, is that I'd love nothing more than spending a few months factoring that merkle-tree datastore out of git(1) into its own library—and then writing a new, much lower-level frontend to expose it. That would be "meeting Git where it lives" in a real sense.)

But, presuming that none of us have time to do that but need to get Real Work done (and that work, for whatever reason, requires using git(1) instead of Mercurial et al), the best thing you can do to "understand Git" is to not try to understand git(1), but rather to understand that merkle-tree library that exists in a nascent form inside git(1)—and then understand git(1) itself as a bad and leaky wrapper around it. As long as you understand what each command you give is doing to the object pool, you can "see through" git(1) and it will no longer be a mysterious dental-cleaning machine, but rather just a simple toothbrush with a really weird handle you have to finagle to get it into your mouth.

Or, to put it another way: as long as you understand the hygienic goal you're attempting to head toward, then you can understand Git in terms of that goal, rather than in terms of its interface.

In this case, the "goal" is building up a content-addressible object pool that you can dump a bunch of people's individual commits into as entirely independent trees (which share objects), that can then be compared and worked with.

git(1) doesn't make very clear that this is the goal. git(1) explains itself only in terms of how to operate the handle of the merkle-tree toothbrush, and where you point it; not in terms of what the brush is doing (cleaning your teeth.) git(1), learned in a cargo-cult manner or taught by someone only familiar with centralized or patch-based SCM, will not result in clean teeth. You'll just be waving the toothbrush around in your mouth. That's git(1)'s fault, of course. But that doesn't mean there isn't a powerful toothbrush-head there, if you look past the handle.

But in git, it's trivial to delete a branch

git -D my-branch

I don't always delete my branches

But when I do, I make a branch called 'rm' first

A good UI exposes the underlying structure where necessary, while offering shortcuts for commonly used tasks or groups of tasks, and most importantly of all, it is consistent. The internal design is elegant and simple, but the UI has grown organically and does not show the same level of care. I'm not convinced the problems with git lie with some fundamental difficulty with its internal model, they are more basic and it simply hasn't had as much care put into the UI as it should. I use the command line, and off the top of my head, problems with the UI are:

Inconsistent options between subcommands, e.g tag and stash

Complex options for everyday commands, e.g. git reset HEAD --file, git rebase -i HEAD~3, git checkout -b mybranch

The mix of options and subcommands, with no clear rationale and unclear naming (things like reset)

Separation of the stages of adding files with committing, I think the default should be combined, with options to separate the stages if required.

The man page assuming understanding of fundamentals for simple commands like git push or rebase

Finally, as an example of how unintuitive the UI is around something as simple as reset/undo - here is one of the top stack overflow questions for git with 12195 votes, which just wants to know how to undo a commit:

http://stackoverflow.com/questions/927358/how-to-undo-last-c...

to which the answers are commands like:

    git reset HEAD~

    git reset --hard HEAD~1

instead of something like this in the default case:

    git undo

Not the mention inconsistency in commands, examples of how to remove something:

  git remote rm foobar

But for branches

  git branch -d my_branch

But for remote branches is :

  git push origin :my_branch

The last one can also be:

    git push origin --delete my_branch

so, rm vs -d vs --delete

Or git push origin -d my_branch, so rm vs -d

git push origin HEAD:mainline git rebase origin/mainline git checkout -b origin/mainline origin/mainline # kappa, caused me hours of pain

Some day we'll hopefully get a re-write of the command line, and replace some of this stuff that is obviously just cruft... and cruft that you could see coming a long time ago (been using it since rails core switched to git). I remember a conversation int the mailing list where people were talking about re-aligning this stuff but they were also worried about adoption and consistency so they left it. Maybe with git version 2.0 they said. This was like 2009.

shell command aliases for now :P

I agree with most of what you said but I strongly disagree with the following:

>Separation of the stages of adding files with committing, I think the default should be combined, with options to separate the stages if required.

My workflow is I make changes which may include many files. Once I'm done with the changes, I like to list the files that have changed, look over the changes to ensure that I don't have any unrelated changes, and if I do then I use "git add -p" for the files that I only want to add part of the changes for, and so at the point where I do that, I need to be able to add files in multiple steps because I only use "git add -p" for the files that need it, and for the remaining files I do regular "git add" since there is no point in having to go through the "git add -p" process with those. Once I have all my changes staged so far, I sometimes remember that there was yet another file that needed to change, so I change that file and stage it for commit. When I'm ready to commit, I review the whole diff that is staged for commit and then I commit it. To me, separate stages of adding files with committing is the only sane default.

This does depend how you work and what you're working on. Since the default is your workflow, it'd be nice to have a command which dealt with the workflow of only changing files you wish to be in the next commit (which I imagine is also very common).

Wouldn't a simple shell alias for `git commit -am` solve this?

That's what I do but we were discussing the git UI, which has many examples like this.

I like my toothbrush, I just wish it didn't hurt so much if I align it incorrectly. Does it really need those sharp edges? Does it need to be made of steel? I know, I should have known better by now, but...

There is this other toothbrush (called "Mercurial") that is made of plastic and has round edges, and according to my dentist, does the job perfectly unless you are among 0.5% of population with REALLY large teeth. But the local shops (GitHub) don't sell it and I have to drive to the other part of town to some obscure shops to get it (BitBucket)...

Facebook uses Mercurial with a REALLY large monorepo with some extensions[0]. Google also has some usage of Mercurial.

[0] https://bitbucket.org/facebook/hg-experimental

I know a lot of people who use hg with github; I don't personally so I'm not sure how it's setup.

Git's GUI is full of horrible features, whcih are almost impossible to learn.

Why does 'git checkout' do double-duty, of checking out a clean copy of a file/directory in the current branch, and checking out a different branch? How does that fit into "learning the mental model of git"

If I have a directory called "master", and a branch called "master", what does "git checkout master" do? How do I force git to do the other one? (I know this, but I shouldn't have to)

I'm not disagreeing with you. I'm more saying that in a world where people "met Git where it lives"—learned the internal model Git is based on—the Git GUI with its misfeatures wouldn't exist.

Picture factoring Git out into 1. a library that manipulates content-addressible manifest-tree pool directories; and 2. a GUI that consumes that library. Now, throw away the second thing. The fact that even #1 hasn't happened already—and that there's no demand for it to happen—is a testament to just how obscure Git makes what it does.

Git's internals could be the next LevelDB; they're that much of a swiss-army knife. But instead, we just have git(1), in all its ugliness.

Actually, git checkout makes perfect sense if you have the git mental model: git checkout makes your index and working copy equivalent to something in the repository. By default, that thing is HEAD, but it can be some other branch if you desire. Checking out a clean copy of a file from the current branch is just a special case of checking out clean copies of files from some other branch.

`git checkout my_branch` does something else that is quite different: it changes the current branch!

Also, `git checkout my_branch` is very different from `git checkout my_branch -- .`

I strongly dislike the double duty of `checkout`. It's made worse by the fact that `git checkout my_branch` will never lose uncommitted changes, while as `git checkout files` will.

It changes the current branch as it brings in clean files from that branch. Bringing in specific clean files from another branch is a special case of bringing in all clean files from another branch. I look at the current HEAD pointer being changed as a side effect when used without file arguments as it simply changing another file: the HEAD symlink. Think of the HEAD symlink as existing above your target commit (and it kind of does) and it makes a lot of sense.

But regardless: the goal of git checkout without file arguments is something you have to have, and if you then ask yourself what tool should implement just the tiny bit of functionality of reverting changes adding a separate command for that seems awkward when that is 99% of what git checkout is doing.

I feel you are over defending git. There is effectively two commands here, why not just give them different names?

The man page starts "switch branches or restore working tree files", which sounds like ramming two things together. Then the manual has to have a special section on how to disambiguate the two uses (files and branches). It would be less work to have an unambiguous command.

Perhaps, at least, make the -- separating files and branches mandatory (so you have to start -- always with files)

> Imagine your dental hygienist telling you they're disappointed in how infrequently and badly you're brushing your teeth. The right response to that isn't blaming the hygienist for making toothbrushes annoying to use, right?

I'm very happy with my electric toothbrush, a purely UI/UX improvement to the problem of toothbrushing.

There's no reason to take it away from me, just to make me realize the pure awesomeness of the procedure of toothbrushing.

An electric toothbrush doesn't paper over the abstraction of brushing teeth. The thing the electric toothbrush is doing for you is a clear, 1:1 automation of the thing you do yourself with a manual toothbrush.

This isn't true of git's high-level commands. If Git was a tooth-cleaning tool, it wouldn't be one that helps you to brush your own teeth. Instead, Git['s high-level command set] would be a fancy machine that asks you to take your teeth out (and hopefully they're dentures), put them into a black box, and then they'll come out cleaned. But sometimes they come out with the teeth rearranged and it's hard to understand why. Sometimes they come out tasting of fluoride and merge-commits. Sometimes you have to take your tongue-ring out before Git will accept your teeth. It's all very mysterious.

Which is silly. Inside the box, Git is brushing your teeth. Inside the box, a very simple thing is going on. It's the abstraction layer that's complicated and unintuitive. The "mystery" is all in how they map their black-box interface to the tooth-brushing internals.

If Git actually was an electric toothbrush—a way to accelerate and ease brushing teeth, but keeping 1:1 clarity on what's going on, and complete control of the result—then nobody would ever be confused about Git. It'd be slightly harder to use than a black box that you put whole dentures into—in about the same way that sed(1) is harder to use than the "Find and Replace" in a text editor—but those familiar with it wouldn't find the workflow any more strenuous.

Lets take this (obviously broken) analogy a bit further.

Toothbrushing, as a skill, is learned early in life and passed over by generations. Best practices, such as in which order to brush the teeth and at which moments during the day we are supposed to use the brush, are repeatedly given during dentist visits, at schools and early in life. Reasons need to be given why to do it this way and these reasons involve some understanding of microbiology, sugary food and plaque. So, also with toothbrushing, it is important to RTFM.

It is important to understand that the task at hand is extremely repetitive, does hardly require a mental model and is shared among all humans.

Now, compare this with git. If I would start using an electric toothbrush without having any understanding of how to use it and what effects I'm trying to achieve, I would hardly be effective. Seeing the dentist bill after a long and painful visit, I would point out the advertisement: "helps prevent carries" and ask what all this toothbrushing is supposed to be about.

I'm not saying the interface of git is intuitive or provides useful affordances. It can be improved. Nevertheless, using a distributed version control system is inherently a difficult task and requires a good understanding to prevent problems down the road. Just like plaque, microbiology and sugary food give a model for brushing, so do blobs, tree objects and commits a good model for (distributed) version control.

Yes but toothbrushing in the first place is a "hygienic" thing to do, rather than a natural thing.

Once you've already internalised the idea of toothbrushing (or source control hygiene), which tool you use is immaterial.

...going with the toothbrush analogy and gits mixed concepts:

The toothbrush actually has a brush on one end and a power drill on the other.

One side can be used for dental hygeine, one for dental surgery (if you're careful).