4 ms·

Git is a success. Claiming otherwise is silly. Git's user interface (porcelain) is not a great thing. Not because it's a CLI, but because it's not great for no

Git is a success. Claiming otherwise is silly. Git's user interface (porcelain) is not a great thing. Not because it's a CLI, but because it's not great for non-power end users. Case in point: Lousy naming inconsistencies. Git supports a staging area, but sometimes calls it a staging area & other times calls it an index. "Index" is a terrible term, because the word has too many other meanings. It's time for them to use one term ("staging area"); the inconsistency makes things harder to explain & use. Git is excessively complicated for simple uses, and it's easy to go wrong. Otherwise there wouldn't be sites like https://ohshitgit.com/ https://ohshitgit.com/ and cartoons like https://xkcd.com/1597/ https://xkcd.com/1597/ Mercurial (hg) shows that it is possible to have a distributed version control system with a simpler and clearer UI. Git has many technical advantages, and I use it all the time. Its fast branching, smart merging, and so on are all awesome. And while some people argue about the staging area, many have found it useful. It's perfectly reasonable to say "I like the tool's capabilities, but its user interface is not so good and needs improvement". That said, git's UI HAS gotten better over time. For example, "git checkout" was overloaded with two different meanings, and more recent versions of git have given them different names (git switch and git restore): https://www.i-programmer.info/news/90-tools/13027-git-adds-switch-and-restore.html https://www.i-programmer.info/news/90-tools/13027-git-adds-s... But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users.

the8472 6y ago
> But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users. Isn't that already covered by the various 3rd-party UIs?
nunez 6y ago
I am okay with Git the CLI being for power users as long as awesome UX developers create excellent user interfaces around it. There are great Git GUIs out there for those that need them, and many of them handle the core workflow (clone, pull and rebase, checkout, commit, push) really well. In fact, once I learned how Git works under the hood, the commands made a lot more sense. Perhaps the problem of distributed version control is just inherently complex?
jjav 6y ago
> because it's not great for non-power end users. Depends on what's the bar for "power users" I suppose. git is easy for the daily use case where nothing special needs to be done and nothing goes wrong. But that's the vast majority of the time, so mostly it's fine. It is when anything out of the ordinary flow needs to be done that it becomes impenetrable and often leads to data loss (or at least, an irrecoverable state which requires restoring from backup). I've been using source control over 30 years now, with the vast majority of those years being on distributed source control systems (starting with Sun's teamware in the mid-90s). git is the one and only where I have had to adopt the practice of making a tarball of the current working dir before any nontrivial operation. And I end up having to use that backup every so often as git gets into some irrecoverable state of confusion. Some of the comments in this and other git threads suggest (and I'll believe it) that if I were to dedicate substantial time to become an expert in the implementation detail and inner working of git, it might be possible to avoid these irrecoverable states. Ok. That right there is an indication of a massive user interface failure.
- xolox 6y ago
  I'm not proud to admit (but I was interested to read that I'm not the only one) that I've gotten into the habit of making a tarball of my working directory and .git directory before large rebase operations between multiple feature branches, because like you I've lost work because git got into awkward states I couldn't get it out of without losing work. A full system backup of my laptops is taken roughly every three hours so it's quite hard for me to lose more work than that. However recovering from a failed rebase without losing changes can also consume a sizable amount of time, which explains why I'm still careful and take precautions anyway.
- fanf2 6y ago
  There’s basically never an irrecoverable state in git, and it’s rare that you can’t recover “lost” data from the reflog. Yes it does require expertise to recover from a cockup, but you will never gain the expertise if you treat it as impossible. Note that you don’t have to avoid getting in a mess: it’s normal, when you are trying to do something unusual or advanced (or impossible in other version control systems) to make a mistake and accidentally blow your foot off, but git gives you the tools to glue your foot back on good as new.

the8472 6y ago

> But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users. Isn't that already covered by the various 3rd-party UIs?

nunez 6y ago

I am okay with Git the CLI being for power users as long as awesome UX developers create excellent user interfaces around it. There are great Git GUIs out there for those that need them, and many of them handle the core workflow (clone, pull and rebase, checkout, commit, push) really well. In fact, once I learned how Git works under the hood, the commands made a lot more sense. Perhaps the problem of distributed version control is just inherently complex?

jjav 6y ago

> because it's not great for non-power end users. Depends on what's the bar for "power users" I suppose. git is easy for the daily use case where nothing special needs to be done and nothing goes wrong. But that's the vast majority of the time, so mostly it's fine. It is when anything out of the ordinary flow needs to be done that it becomes impenetrable and often leads to data loss (or at least, an irrecoverable state which requires restoring from backup). I've been using source control over 30 years now, with the vast majority of those years being on distributed source control systems (starting with Sun's teamware in the mid-90s). git is the one and only where I have had to adopt the practice of making a tarball of the current working dir before any nontrivial operation. And I end up having to use that backup every so often as git gets into some irrecoverable state of confusion. Some of the comments in this and other git threads suggest (and I'll believe it) that if I were to dedicate substantial time to become an expert in the implementation detail and inner working of git, it might be possible to avoid these irrecoverable states. Ok. That right there is an indication of a massive user interface failure.

xolox 6y ago
I'm not proud to admit (but I was interested to read that I'm not the only one) that I've gotten into the habit of making a tarball of my working directory and .git directory before large rebase operations between multiple feature branches, because like you I've lost work because git got into awkward states I couldn't get it out of without losing work. A full system backup of my laptops is taken roughly every three hours so it's quite hard for me to lose more work than that. However recovering from a failed rebase without losing changes can also consume a sizable amount of time, which explains why I'm still careful and take precautions anyway.
fanf2 6y ago
There’s basically never an irrecoverable state in git, and it’s rare that you can’t recover “lost” data from the reflog. Yes it does require expertise to recover from a cockup, but you will never gain the expertise if you treat it as impossible. Note that you don’t have to avoid getting in a mess: it’s normal, when you are trying to do something unusual or advanced (or impossible in other version control systems) to make a mistake and accidentally blow your foot off, but git gives you the tools to glue your foot back on good as new.