5 ms·

But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks.

But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks. The idea that git is good because it is difficult to use is just "git snobbery", as is the idea that it must be difficult because it's a DVCS. There's nothing to stop git having two levels of the API, one exposed for tools to build off of with the full complexity and another for every day use.

Sir_Cmpwn 7y ago
This is the same argument that suggests Squarespace is better than HTML & CSS. Maybe true for some people - but not the typical HN audience, I imagine. You use git all day, every day. It's worth it to learn it inside and out, and the design assumes users who are willing to make that investment. If you assume everyone learns the primitives, then the rest of git's design makes sense as an organic evolution of that. And for anyone who doesn't know the primitives, I posted a brief summary on Mastodon the other day: https://cmpwn.com/@sir/102038690003388821 https://cmpwn.com/@sir/102038690003388821 Also recommend Pro Git's chapter on git internals.
- Espressosaurus 7y ago
  Nah. It's a UI issue. Even when you know the primitives, the counterintuitive randomness of what is a command vs. what is a switch on a different command vs. something that can be done in three different ways using different combinations of commands and switches makes it a clusterfuck to interface with until you memorize everything. Contrast to something like mercurial where once you know the concept, you either know how to do it, or you know the command that will give you the help for how to do it. It's generally not going to be some switch on an unrelated command because the UI was actually designed and not simply cobbled together.
- eterm 7y ago
  This isn't HTML & CSS vs squarespace, and to butcher the analogy this is more like CSS vs Sass/SCSS. CSS is the internal API which does everything but Sass is an API which exposes that in a much more beautiful way. I don't need to know how postgres does paging, indexing, tree diffs, etc to be able to write good SQL. I don't need to know how typescript compiles to javascript to use typescipt. I don't need to know how my engine works to drive my car. I use all of those every day. But the suggestion here is that as every day users of git should learn git internals to be able to use the tool better. That's a tooling failure. It's not a failure of the git design or git fundamentals, it's a failure of the git cli.
Hello71 7y ago
http://man7.org/linux/man-pages/man1/git.1.html http://man7.org/linux/man-pages/man1/git.1.html GIT COMMANDS We divide Git into high level ("porcelain") commands and low level ("plumbing") commands.
- np_tedious 7y ago
  Being that rebase is under "porcelain", would you agree the UI ought to be improved? I'm not sure if I do, but that's the conclusion the man page + your comment would seem to support.
Espressosaurus 7y ago
Mercurial's interface is just fine, and these days it's just as powerful as Git. Things could be better. There's an existence proof. It just lost the mindshare war and so now we're stuck with Git, which I still have to look up basic syntax for because its command set is contradictory and makes no sense. (Is it git <x>? git <y> --x? git <z> <a-b>? Something else entirely? Who knows!)
- deleted 7y ago
  [deleted]
- guitarbill 7y ago
  I used to agree with this, now I've stopped worrying. Because if git is the worst part of your workflow, that's a great problem to have. But at many places, git is the best part. (I've also had to work with various IBM CVS, and they are universally garbage. When I get frustrated at git, all I have to do is think back to those.) So yes, Mercurial is better, but is it worth the effort? Not in my experience.
  - hnthrowaway919 7y ago
    I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with rebasing/merging into whatever branch you want to put it in/on. I also think there's something to be said for a CVS system that is built for teams that work together daily, compared to a system that's built for a "remote contributor" model. That being said, I use git daily and find that I'm able to do everything I want and more, so I'm not looking to make a switch. Unfortunately, most people don't care to learn how to use git beyond "checkout, commit, push, call for help".
    - guitarbill 7y ago
      There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity. I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restricted creation of streams, meaning you simply could not branch at all if I'm remembering), and the capability to stash changes/switch branches to work on different work items if one was blocked was also more cumbersome. Code review was terrible. A centralised paradigm does simplify things a lot mentally, but the workflow suffers IMO.
dahart 7y ago
Git does have two levels of the API explicitly, one for tools (“plumbing”) and one for every day use (“porcelain”). I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion. Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or how to simplify git. Lots of people have tried to make a higher level porcelain, and the issue isn’t going away. You are welcome to suggest & create a git wrapper that makes it simpler and less dangerous. Perforce is easier to learn, so you might try using that instead. I use both and I’m becoming more and more frustrated with Perforce because git is so much more flexible and safer and easier to use once you learn how to use git.
- AlexTWithBeard 7y ago
  The main problem with git is that it tries to be two things at once: a change management system and a version control system. For the former you want flexible history, distributed repos and freedom to do whatever you want. For the latter the history should be sacrosanct and the repository is better be more or less centralized. git tries to sit on both chairs and therefore has to adapt a quite awkward position.
  - dahart 7y ago
    I totally don’t understand your implied semantic difference between “change management” and “version control”. Those sound like exactly the same thing to me. ;) I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.
    - AlexTWithBeard 7y ago
      For me "change management" is akin to IntelliJ's shelf: you can have a bunch of changes, you can combine them in lists, you can shuffle the changes between these lists and selectively apply them. Editing is the king. I should totally be able to destroy five years of my work without a way to recover. "Version control" is a log. I should be able to return to any point in history at any time. I should not be able to destroy this history no matter what I do. The history should be backed up in a remote location. With git every once in a while these two come into conflict: I'm using my branch as a change management system and then someone else pulls that branch and makes a couple of changes on it. Then I force push and the mess begins. Regarding centralized repository: say, I have two working copies. In goode olde subversion there was the "master" version in trunk and two local versions, one per working copy. Three versions altogether. Pretty clear which is which. Now in git I have: - master in origin repo - origin/master in wc1 - master in wc1 - actual file in wc1 - all the same in wc2 Seven potentially different versions of the same exact file. That's even without mentioning a stash.
tasuki 7y ago
> The idea that git is good because it is difficult to use Git is good because it is extremely elegantly designed. There are blobs, trees, commits, and refs. When you understand them, you understand pretty much everything about git. And yes, the interface is a mess.

Sir_Cmpwn 7y ago

This is the same argument that suggests Squarespace is better than HTML & CSS. Maybe true for some people - but not the typical HN audience, I imagine. You use git all day, every day. It's worth it to learn it inside and out, and the design assumes users who are willing to make that investment. If you assume everyone learns the primitives, then the rest of git's design makes sense as an organic evolution of that. And for anyone who doesn't know the primitives, I posted a brief summary on Mastodon the other day: https://cmpwn.com/@sir/102038690003388821 https://cmpwn.com/@sir/102038690003388821 Also recommend Pro Git's chapter on git internals.

Espressosaurus 7y ago
Nah. It's a UI issue. Even when you know the primitives, the counterintuitive randomness of what is a command vs. what is a switch on a different command vs. something that can be done in three different ways using different combinations of commands and switches makes it a clusterfuck to interface with until you memorize everything. Contrast to something like mercurial where once you know the concept, you either know how to do it, or you know the command that will give you the help for how to do it. It's generally not going to be some switch on an unrelated command because the UI was actually designed and not simply cobbled together.
eterm 7y ago
This isn't HTML & CSS vs squarespace, and to butcher the analogy this is more like CSS vs Sass/SCSS. CSS is the internal API which does everything but Sass is an API which exposes that in a much more beautiful way. I don't need to know how postgres does paging, indexing, tree diffs, etc to be able to write good SQL. I don't need to know how typescript compiles to javascript to use typescipt. I don't need to know how my engine works to drive my car. I use all of those every day. But the suggestion here is that as every day users of git should learn git internals to be able to use the tool better. That's a tooling failure. It's not a failure of the git design or git fundamentals, it's a failure of the git cli.

Hello71 7y ago

http://man7.org/linux/man-pages/man1/git.1.html http://man7.org/linux/man-pages/man1/git.1.html GIT COMMANDS We divide Git into high level ("porcelain") commands and low level ("plumbing") commands.

np_tedious 7y ago
Being that rebase is under "porcelain", would you agree the UI ought to be improved? I'm not sure if I do, but that's the conclusion the man page + your comment would seem to support.

Espressosaurus 7y ago

Mercurial's interface is just fine, and these days it's just as powerful as Git. Things could be better. There's an existence proof. It just lost the mindshare war and so now we're stuck with Git, which I still have to look up basic syntax for because its command set is contradictory and makes no sense. (Is it git <x>? git <y> --x? git <z> <a-b>? Something else entirely? Who knows!)

deleted 7y ago
[deleted]
guitarbill 7y ago
I used to agree with this, now I've stopped worrying. Because if git is the worst part of your workflow, that's a great problem to have. But at many places, git is the best part. (I've also had to work with various IBM CVS, and they are universally garbage. When I get frustrated at git, all I have to do is think back to those.) So yes, Mercurial is better, but is it worth the effort? Not in my experience.
- hnthrowaway919 7y ago
  I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with rebasing/merging into whatever branch you want to put it in/on. I also think there's something to be said for a CVS system that is built for teams that work together daily, compared to a system that's built for a "remote contributor" model. That being said, I use git daily and find that I'm able to do everything I want and more, so I'm not looking to make a switch. Unfortunately, most people don't care to learn how to use git beyond "checkout, commit, push, call for help".
  - guitarbill 7y ago
    There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity. I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restricted creation of streams, meaning you simply could not branch at all if I'm remembering), and the capability to stash changes/switch branches to work on different work items if one was blocked was also more cumbersome. Code review was terrible. A centralised paradigm does simplify things a lot mentally, but the workflow suffers IMO.

dahart 7y ago

Git does have two levels of the API explicitly, one for tools (“plumbing”) and one for every day use (“porcelain”). I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion. Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or how to simplify git. Lots of people have tried to make a higher level porcelain, and the issue isn’t going away. You are welcome to suggest & create a git wrapper that makes it simpler and less dangerous. Perforce is easier to learn, so you might try using that instead. I use both and I’m becoming more and more frustrated with Perforce because git is so much more flexible and safer and easier to use once you learn how to use git.

AlexTWithBeard 7y ago
The main problem with git is that it tries to be two things at once: a change management system and a version control system. For the former you want flexible history, distributed repos and freedom to do whatever you want. For the latter the history should be sacrosanct and the repository is better be more or less centralized. git tries to sit on both chairs and therefore has to adapt a quite awkward position.
- dahart 7y ago
  I totally don’t understand your implied semantic difference between “change management” and “version control”. Those sound like exactly the same thing to me. ;) I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.
  - AlexTWithBeard 7y ago
    For me "change management" is akin to IntelliJ's shelf: you can have a bunch of changes, you can combine them in lists, you can shuffle the changes between these lists and selectively apply them. Editing is the king. I should totally be able to destroy five years of my work without a way to recover. "Version control" is a log. I should be able to return to any point in history at any time. I should not be able to destroy this history no matter what I do. The history should be backed up in a remote location. With git every once in a while these two come into conflict: I'm using my branch as a change management system and then someone else pulls that branch and makes a couple of changes on it. Then I force push and the mess begins. Regarding centralized repository: say, I have two working copies. In goode olde subversion there was the "master" version in trunk and two local versions, one per working copy. Three versions altogether. Pretty clear which is which. Now in git I have: - master in origin repo - origin/master in wc1 - master in wc1 - actual file in wc1 - all the same in wc2 Seven potentially different versions of the same exact file. That's even without mentioning a stash.

tasuki 7y ago

> The idea that git is good because it is difficult to use Git is good because it is extremely elegantly designed. There are blobs, trees, commits, and refs. When you understand them, you understand pretty much everything about git. And yes, the interface is a mess.