Hacker News Reader

> My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation.

Dozens have, but by the time their replacement porcelain gets anywhere near useful they’ve attained a grasp of the plumbing more than good enough they don’t need it anymore.

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface?

Mastery of structural elegance doesn’t mean you have also mastered interface and experience. In fact it’s often not the case.

> I can't offhand think of another piece of software where "the model is elegant but the interface is confusing" is such a common critique.

Every database. The relational model is a beautiful thing, sql is a horrendous shit-show.

> Every database. The relational model is a beautiful thing, sql is a horrendous shit-show.

Amen. We probably disagree on if we need less abstraction or better abstraction though.

For all the griping that git gets I really think it could be much worse. It's a somewhat inelegant shrink-wrap over its data structures but at least I can get at all the pieces I need.

I get that SQL works well for ad-hoc analysis and business cases, and a query planner is super useful there, but for service to service calls I'd love a language that let's me refer to the tables, the b-trees, row-ids, and lets me tell it what to do.

> but for service to service calls I'd love a language that let's me refer to the tables, the b-trees, row-ids

Quite Insane :)

Ok, more helpfully, what possible value would you get if the DB gave you access to those?

It seems then what is needed is a better way to onboard people to get them to that state of knowing.

JavaScript is another example. The core model is simple: Closures + dictionaries. But the syntax is clunky and confusing.

> My question is why hasn't anyone come along and fixed it?

Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user.

Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches and tags) because humans need symbolic names (because we can't memory SHA-1 hashes, or any hashes). Object and commit hashes function as pointers or inode numbers. Symbolic commit names function as hard links.

If you understand the Unix filesystem, you can understand Git.

Everything else follows from these things.

Merges create new objects referenced from the merge commit.

Rebase is just a script around cherry-pick.

Cherry-pick is just applying a delta from a commit and then re-committing.

Everything is copy-on-write except the symbolic names (branch names, tag names).

There -- I've just told you everything you need to know about the model. And all of that trivially carries over to the UI.

The problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.

Then create yourself some convenient command aliases. It's not like someone is going to create a layer over git and make it 10x better by fixing some inconsistencies. Plus, whatever benefit is added you'll still have to learn the layer below the abstraction.. eventually.. to be productive. Just not worth it. You may as well learn git. You'll use it for the rest of your career. And that's a breath of fresh air that I can say that confidently about a technology.

If I've partially staged some changes, why can't I stash and unstash them and get back to the same state?

The problems with git are not the commits and the DAG. It's all the ancillary stuff that's inconsistent and confusing.

You can, I think, with `git stash push foo.js`

You can't; depending on the options that will either stash your staged changes to foo.js, stash your unstaged changes to foo.js, or stash both but flatten them so that when you apply them they're all staged (or all unstaged). There's no way to stash it so that you can unstash it and get it back how it is now.

Yeah, I’ve actually found WIP commits and a hook to block them from being pushed end up working better than stashes, so I haven’t spent a lot of time figuring out the complexities of stashes.

My workflow here would be something like:

    git checkout -b save
    git commit # save staged changes
    git add .
    git commit -m WIP # save unstaged changes 
    git checkout -

I would either unstage then stash, or commit, create a branch to point to the new HEAD, stash, then reset the branch to the previous HEAD.

To use an example from TFA: how does Reset make any sense based on the Unix filesystem?

`git reset` is analogous to filesystem restore from backup.

Next question.

Note that the analogy to filesystems is not exact. The point is that you can understand higher-level operations in terms of lower level ones / gain insight into higher level operations from knowledge of the lower level concepts. As opposed to the cognitive burden of incomprehensible magic, where every time you get in trouble you've no idea what to do.

> Cherry-pick is just applying a delta from a commit and then re-committing.

That’s trivially not true from its conflict resolution abilities. A cherrypick is a merge which does not create a merge commit, it’s a lot “smarter” that “git show -p | git patch”

> My question is why hasn't anyone come along and fixed it?

There's been dozens of "replacements"/frontends/guis for git, off the top of my head: gitless, magit, tortoise git, gitkraken. Heres a whole mess of em: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,...

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface?

I think this is 66% because the operations are on the tree/nodes themselves, and not like, on "versions", branches, or some other skeumorphic abstraction. It's very bare metal. If you know how the command operates on the tree, you know how to conduct the actual action desired. I think the rest is due to cruft/familiarity - once you build that mental model, it works extremely well. So it's vi-like with a steep learning curve and arcane interface, but once you "git good", it's phenomenally productive.

I believe I will never figure out when I have to use "remove" "delete" "-d". These naming inconsistencies make it a lot harder than necessary

A porcelain whose only purpose is to address those inconsistencies would be wonderful.

> Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc?

I've used svn and git extensively, but after getting very used to git, i tried working on a project that used mercurial and walked away completely confused by how it works. With "branches" being completely different beasts that i couldn't understand and unsure when it was appropriate to use bookmarks instead. It completely baffles me that people find it better than git's super straightforward dag-of-snapshots model and I reject the idea that it is simpler or more intuitive.

If you're coming from git, this is what you need to do to understand Mercurial: don't worry about Mercurial's branches, ever. Whenever you want to use the term 'branch' from git, translate it to 'bookmark'. Mercurial's branches correspond more directly to svn's branches--they're immutable properties of a revision--but it's not a terribly useful property, and you can forget about them entirely and be perfectly productive.

Although note that unlike git, you don't need to use Mercurial's bookmarks since Mercurial is perfectly happen to let commits sit around without having names pointing to them.

> > But if you try to understand the commands without the model, you will suffer, because the commands do not make sense.

> I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc?

What about svn is intuitive? It was never intuitive to me. It always felt confusing.

Trying to deal with any system without having a mental model (even if high level) of what's going on will always cause problems. How do I know if `svn update` screws up my uncommitted changes? I never felt safe with svn because I had no idea what the commands could do to my files.

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? This isn't so much me griping about git (although I am) but more a curious case for design theory. Would love to read serious analysis. I can't offhand think of another piece of software where "the model is elegant but the interface is confusing" is such a common critique.

This is actually pretty common. You just don't notice it when you are used to the interface.

The unix file system and command line tools come to mind.

Isn't that jujutsu?[1]

> Jujutsu is a Git-compatible DVCS. It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system).

> Compatible with Git > > Jujutsu has two backends. One of them is a Git backend (the other is a native one 1). This lets you use Jujutsu as an alternative interface to Git. The commits you create will look like regular Git commits. You can always switch back to Git.

[1] https://github.com/martinvonz/jj

Past discussion about Jujutsu: https://news.ycombinator.com/item?id=30398662

Tons of people have tried creating GUIs to make using git easier, and many do, but where they fail is when they try and change the terminology to make it easier to understand.

GitKraken + git cli works like a dreamteam. GitKraken for 80% of the interactions like staging lines, commiting, browsing the history. Git cli for the 20% long tail of special operations

TortoiseGit works without loss of generality. In many respects it may even be more ergonomic.

TortoiseSVN is IMO the best way to do SVN. I never got into TortoiseGit though.

They have, several times. But it's very hard for a third party command line interface to outcompete the native one.

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface?

This is the consequence of elegance. Elegance at one level usually is characterized by being very data-agnostic, very workflow-agnostic, etc. This leads to anything built on top of it to be so generic its unusable or at least very awkward.

Pretty much everyone who works with git daily has a set of script to do the actual day-to-day work. The git command is too awful to use otherwise.

Not only have I never thought about or used a script for day-to-day stuff in more than a decade of using git, I don't know a single person who does...

It's really not as hard or cumbersome as this comment section would have you believe

I have a handful of aliases, but scripts? What do you script in git? My aliases revolve around pulling MRs from GitLab/GitHub, having some nice pretty formats and pushing things with custom push options consumed by CI. Not much else there.