9 ms·

> 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

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

dariusj18 4y ago
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.
- WanderPanda 4y ago
  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
- tigerlily 4y ago
  TortoiseGit works without loss of generality. In many respects it may even be more ergonomic.
  - dariusj18 4y ago
    TortoiseSVN is IMO the best way to do SVN. I never got into TortoiseGit though.
kortex 4y ago
> 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,_and_tools 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.
- WanderPanda 4y ago
  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
  - ziml77 4y ago
    A porcelain whose only purpose is to address those inconsistencies would be wonderful.
radarsat1 4y ago
> 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.
- jcranmer 4y ago
  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.
masklinn 4y ago
> 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.
- kjeetgill 4y ago
  > 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.
  - zasdffaa 4y ago
    > 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?
- tmaly 4y ago
  It seems then what is needed is a better way to onboard people to get them to that state of knowing.
- goto11 4y ago
  JavaScript is another example. The core model is simple: Closures + dictionaries. But the syntax is clunky and confusing.
cryptonector 4y ago
> 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.
- yCombLinks 4y ago
  The problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.
  - waynesonfire 4y ago
    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.
- lmm 4y ago
  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.
pierrebai 4y ago
> 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.
- ingobingo 4y ago
  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
- seba_dos1 4y ago
  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.
hsn915 4y ago
> > 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.
- brigandish 4y ago
  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 https://github.com/martinvonz/jj
  - glandium 4y ago
    Past discussion about Jujutsu: https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662
stevage 4y ago
They have, several times. But it's very hard for a third party command line interface to outcompete the native one.

dariusj18 4y ago

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.

WanderPanda 4y ago
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
tigerlily 4y ago
TortoiseGit works without loss of generality. In many respects it may even be more ergonomic.
- dariusj18 4y ago
  TortoiseSVN is IMO the best way to do SVN. I never got into TortoiseGit though.

kortex 4y ago

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

WanderPanda 4y ago
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
- ziml77 4y ago
  A porcelain whose only purpose is to address those inconsistencies would be wonderful.

radarsat1 4y ago

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

jcranmer 4y ago
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.

masklinn 4y ago

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

kjeetgill 4y ago
> 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.
- zasdffaa 4y ago
  > 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?
tmaly 4y ago
It seems then what is needed is a better way to onboard people to get them to that state of knowing.
goto11 4y ago
JavaScript is another example. The core model is simple: Closures + dictionaries. But the syntax is clunky and confusing.

cryptonector 4y ago

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

yCombLinks 4y ago
The problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.
- waynesonfire 4y ago
  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.
lmm 4y ago
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.

pierrebai 4y ago

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

ingobingo 4y ago
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
seba_dos1 4y ago
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.

hsn915 4y ago

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

brigandish 4y ago
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 https://github.com/martinvonz/jj
- glandium 4y ago
  Past discussion about Jujutsu: https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662

stevage 4y ago

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