> 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? This seems like a similar situation as dpkg/apt. The underlying design has been settled but we desperately need a better interface.
> Git has an elegant and powerful underlying model based on a few simple concepts
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.
> 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.
> 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.
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.
`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.
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 -
> 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 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.
> 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.
> 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.
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
> 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.
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.
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? This seems like a similar situation as dpkg/apt. The underlying design has been settled but we desperately need a better interface.
> Git has an elegant and powerful underlying model based on a few simple concepts
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.