5 ms·

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault. Good software is not like that. Good software is the opposite of all of that. Git is the industry standard, and I have just accepted that we aren't going to get anything better, but whereas it might make sense for the Linux kernel dev community, it is not good software, and I suspect that it's not just the UI that's the problem. Lots of non-devs also have the problem of wanting to have multiple people edit the same document, track changes, and occasionally merge them. I would never recommend that they use git, and I see no evidence that it is ever spreading beyond the dev community in any significant way. There's a good reason for that.

fuball63 6y ago
What do you recommend in these cases? People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". My mind goes straight to VCS, but git is too hard to get them quickly up and running. I tried SVN one time, which is a little simpler, but still didn't catch on with the person I was showing it to.
- whimsicalism 6y ago
  > People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". IMO nothing remotely like version control nor anything that requires a command line is going to click for someone in a non-technical field.
einpoklum 6y ago
If you rm -r some_common_dir/ or echo foo > important_file.txt that would also be perceived as your fault. And yet, command shells are pretty good software. As for non-devs editing the same document - unless that document is text (which typically it isn't for non-devs), I would probably not use git on them either.
- madhadron 6y ago
  > And yet, command shells are pretty good software. This is a contentious statement. Fred Brooks himself calls the separate command language, which began with JCL on OS/360, a mistake.
  - rwallace 6y ago
    Now that is interesting! Do you remember where he said this?
    - madhadron 6y ago
      In this interview at least: https://cacm.acm.org/magazines/2015/11/193333-an-interview-with-fred-brooks/fulltext https://cacm.acm.org/magazines/2015/11/193333-an-interview-w...
SoSoRoCoCo 6y ago
Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly. The author's idea of putting an abstraction on top of git is the way to go. As an analogy, Git is a great toolbox, but sometimes you need a plumber. I like how apt and apt-get came into being on Ubuntu. The comments about the logical inconsistencies in Gits command line are a clue. When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. But that is also a legacy of Unix/BSD. Consider `du` and `find`. Both have an option for max depth, but is it --max-depth, -maxdepth, --maxdepth, -d, or -m (or even -L for `tree`). There is a lack of consistency that is a rite of passive for Unix/BSD acolytes that even Gnu didn't fix... C'est la vie? Or maybe a /bin rewrite? bahahahaa who am I kidding. There's no question Git is a powerful tool, it just needs to evolve and gain some consistency. And I think the answer is a higher level abstraction. And for the love of Benji, NOT a GUI.
- gizmo385 6y ago
  > When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.
  - rossdavidh 6y ago
earthboundkid 6y ago
> Git is the democracy of programming: it is the worst tool for version control, except all those other tools that have been tried from time to time. https://blog.carlmjohnson.net/post/2018/git-gud/ https://blog.carlmjohnson.net/post/2018/git-gud/
sixstringtheory 6y ago
> Good software is not like that You can't just say this without providing an example of what you think is good software, as, after all, good and bad are subjective and not agreed upon by all people for all things, as evidenced in this thread.
- develop7 6y ago
  Mercurial, Pijul, Bazaar, Subversion In fact, it's every fucking version control system other than Git.
- sicariusnoctis 6y ago
  Anu (successor of Pijul), of course. ;) https://news.ycombinator.com/item?id=25001539 https://news.ycombinator.com/item?id=25001539
TheKarateKid 6y ago
> If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault. Ready to be downvoted into oblivion for this, but: This is how a lot of the Linux/FOSS community is so it makes sense that Git is too, sadly. Things have gotten a lot better with the attitude these days, but you know it's bad when StackOverflow needs to issue guidelines on being polite and how to answer questions without being rude/condescending.

fuball63 6y ago

What do you recommend in these cases? People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". My mind goes straight to VCS, but git is too hard to get them quickly up and running. I tried SVN one time, which is a little simpler, but still didn't catch on with the person I was showing it to.

whimsicalism 6y ago
> People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". IMO nothing remotely like version control nor anything that requires a command line is going to click for someone in a non-technical field.

einpoklum 6y ago

If you rm -r some_common_dir/ or echo foo > important_file.txt that would also be perceived as your fault. And yet, command shells are pretty good software. As for non-devs editing the same document - unless that document is text (which typically it isn't for non-devs), I would probably not use git on them either.

madhadron 6y ago
> And yet, command shells are pretty good software. This is a contentious statement. Fred Brooks himself calls the separate command language, which began with JCL on OS/360, a mistake.
- rwallace 6y ago
  Now that is interesting! Do you remember where he said this?
  - madhadron 6y ago
    In this interview at least: https://cacm.acm.org/magazines/2015/11/193333-an-interview-with-fred-brooks/fulltext https://cacm.acm.org/magazines/2015/11/193333-an-interview-w...

SoSoRoCoCo 6y ago

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly. The author's idea of putting an abstraction on top of git is the way to go. As an analogy, Git is a great toolbox, but sometimes you need a plumber. I like how apt and apt-get came into being on Ubuntu. The comments about the logical inconsistencies in Gits command line are a clue. When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. But that is also a legacy of Unix/BSD. Consider `du` and `find`. Both have an option for max depth, but is it --max-depth, -maxdepth, --maxdepth, -d, or -m (or even -L for `tree`). There is a lack of consistency that is a rite of passive for Unix/BSD acolytes that even Gnu didn't fix... C'est la vie? Or maybe a /bin rewrite? bahahahaa who am I kidding. There's no question Git is a powerful tool, it just needs to evolve and gain some consistency. And I think the answer is a higher level abstraction. And for the love of Benji, NOT a GUI.

gizmo385 6y ago
> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it. I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.
- rossdavidh 6y ago

earthboundkid 6y ago

> Git is the democracy of programming: it is the worst tool for version control, except all those other tools that have been tried from time to time. https://blog.carlmjohnson.net/post/2018/git-gud/ https://blog.carlmjohnson.net/post/2018/git-gud/

sixstringtheory 6y ago

> Good software is not like that You can't just say this without providing an example of what you think is good software, as, after all, good and bad are subjective and not agreed upon by all people for all things, as evidenced in this thread.

develop7 6y ago
Mercurial, Pijul, Bazaar, Subversion In fact, it's every fucking version control system other than Git.
sicariusnoctis 6y ago
Anu (successor of Pijul), of course. ;) https://news.ycombinator.com/item?id=25001539 https://news.ycombinator.com/item?id=25001539

TheKarateKid 6y ago

> If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault. Ready to be downvoted into oblivion for this, but: This is how a lot of the Linux/FOSS community is so it makes sense that Git is too, sadly. Things have gotten a lot better with the attitude these days, but you know it's bad when StackOverflow needs to issue guidelines on being polite and how to answer questions without being rude/condescending.