4 ms·

Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsul

by 13of40 10y ago

Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsulating the #1 scenario, which is "I copied some stuff locally and changed it and now I want to put it back on the server so other people can get my stuff (and of course I want undo in case I mess up and merge in case we both change the same file)" without inventing their own special opaque language and concepts for everything. We all intuitively understand file systems somehow but with source control it's way too easy to miss something subtle and end up with a steaming pile of merge conflicts, broken pulls, incomplete fetch requests, unpublished tags, and borked integrations instead of your awesome code ending up on the server so others can share in the awesomeness.

scrollaway 10y ago
Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results. In other word, git's great internally... externally it just has a poor UI. But what's new there.
- ben_jones 10y ago
  I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.
  - ufo 10y ago
    I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation. I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial. https://xkcd.com/1597/ https://xkcd.com/1597/
    - ben_jones 10y ago
      I.. yup. That comic never ceases to amaze me.
    - mikaraento 10y ago
      I don't completely agree. While git definitely could still be more polished, the problem it tries to solve is fundamentally complicated. Git does a good job of cleanly modeling the graph of distributed changes and providing a set of useful operations on that graph. The disagreement is more about whether somebody has learned or should learn that underlying graph.
    - deleted 10y ago
      [deleted]
  - blakeyrat 10y ago
    If Git were well-designed, it'd be free of rough edges and "gotchas", and it would teach you how to use it as you used it by making use of discoverability. If Git were a well-engineered piece of software, it wouldn't even have a manual (certainly not a "required reading" manual).
- InclinedPlane 10y ago
  The purpose of software is only partially to solve problems, the rest of the purpose is to serve as a liaison between user space and implementation space. Many tools with bad UI forget about that second part, but human factors are hugely important in the success of software.
- blakeyrat 10y ago
  Every source control system has had a terrible UI. I mean, most of them don't even really make an attempt. (Unless you count things like Time Machine or Microsoft Word's revision tracking, those are both acceptably decent.) But Git is a whole 'nother layer of awful beyond all of them. Another one of the "reasons I can't get along with Linux users" is that they see something like Git and just kind of shrug and deal with it instead of getting angry that we have a piece of basically brand new software that was built without even attempting to incorporate any UI concepts we knew about at the time it was written. And since it's a CLI that about a thousand other scripts and tools consume (instead of having proper separation of the human interface from the machine interface), it basically cannot be improved at this point, not without breaking thousands of third-party tools. Sigh.
  - JoeAltmaier 10y ago
    That's pretty much true of the entire baroque edifice of unix-based CLI tools. They are what they are, and they can't really change much. Its an increasing hill to climb to become proficient, and those already comfortable have no incentive to change it.
    - blakeyrat 10y ago
      Which is awful, because there's nothing stopping usability development in CLI environments (look at Cortana or Siri, for example, or to a lesser extent PowerShell) except that awful stagnation. People shouldn't have to bend their brain to work with a machine. The machine should be designed to work with human brains. And to be that snarky person for a second: I've heard a lot of people who actually love Linux CLIs still complaining about Git's weird-ass behaviors. https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...
- deleted 10y ago
  [deleted]
matt_wulfeck 10y ago
I'm inclined to agree, but only on the part of resolving coficts when two truths diverge. Git does this well if everything is checked into one repo. Submodules are kind of a pain. I wish they were represented better via the CLI.
jdavis703 10y ago
The only time I've wound up with a steaming mess was when I was first learning Git. I've been using it for 5 years now, and have done some pretty crazy things with it, and yet haven't screwed up the master branch since then. However to get to that point I had to read "Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development" (this was after royally fucking up and not wanting to get fired).
- thomasvarney723 10y ago
  Would you care to share that story?
  - jdavis703 10y ago
    Basically Tuesday was the weekly deploy day. Master got screwed up from both a code perspective (incorrect conflict resolution), and then my fixes to rewrite history messed things up even more, blocking the release. Basically I didn't understand how Git worked (and me nor anyone else at my company apparently knew about reflogs).
    - skrebbel 10y ago
      And they'd fire you over that? Woa, horrid place.
      - jdavis703 10y ago
        Well I wasn't scared of being fired for that one mistake. But I didn't want to make it again, because after the second time you've just shown yourself to be an ass. Most places I've worked at are like "we allow you to make mistakes, but not the same mistake twice."
      - deleted 10y ago
        [deleted]
microcolonel 10y ago
"and of course I want undo in case I mess up and merge in case we both change the same file" That's what git reflog is for; and if you're paranoid you can set it up so it doesn't garbage collect as aggressively or at all.

by 13of40 10y ago

scrollaway 10y ago

Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results. In other word, git's great internally... externally it just has a poor UI. But what's new there.

ben_jones 10y ago
I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.
- ufo 10y ago
  I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation. I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial. https://xkcd.com/1597/ https://xkcd.com/1597/
  - ben_jones 10y ago
    I.. yup. That comic never ceases to amaze me.
  - mikaraento 10y ago
    I don't completely agree. While git definitely could still be more polished, the problem it tries to solve is fundamentally complicated. Git does a good job of cleanly modeling the graph of distributed changes and providing a set of useful operations on that graph. The disagreement is more about whether somebody has learned or should learn that underlying graph.
  - deleted 10y ago
    [deleted]
- blakeyrat 10y ago
  If Git were well-designed, it'd be free of rough edges and "gotchas", and it would teach you how to use it as you used it by making use of discoverability. If Git were a well-engineered piece of software, it wouldn't even have a manual (certainly not a "required reading" manual).
InclinedPlane 10y ago
The purpose of software is only partially to solve problems, the rest of the purpose is to serve as a liaison between user space and implementation space. Many tools with bad UI forget about that second part, but human factors are hugely important in the success of software.
blakeyrat 10y ago
Every source control system has had a terrible UI. I mean, most of them don't even really make an attempt. (Unless you count things like Time Machine or Microsoft Word's revision tracking, those are both acceptably decent.) But Git is a whole 'nother layer of awful beyond all of them. Another one of the "reasons I can't get along with Linux users" is that they see something like Git and just kind of shrug and deal with it instead of getting angry that we have a piece of basically brand new software that was built without even attempting to incorporate any UI concepts we knew about at the time it was written. And since it's a CLI that about a thousand other scripts and tools consume (instead of having proper separation of the human interface from the machine interface), it basically cannot be improved at this point, not without breaking thousands of third-party tools. Sigh.
- JoeAltmaier 10y ago
  That's pretty much true of the entire baroque edifice of unix-based CLI tools. They are what they are, and they can't really change much. Its an increasing hill to climb to become proficient, and those already comfortable have no incentive to change it.
  - blakeyrat 10y ago
    Which is awful, because there's nothing stopping usability development in CLI environments (look at Cortana or Siri, for example, or to a lesser extent PowerShell) except that awful stagnation. People shouldn't have to bend their brain to work with a machine. The machine should be designed to work with human brains. And to be that snarky person for a second: I've heard a lot of people who actually love Linux CLIs still complaining about Git's weird-ass behaviors. https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...
deleted 10y ago
[deleted]

matt_wulfeck 10y ago

I'm inclined to agree, but only on the part of resolving coficts when two truths diverge. Git does this well if everything is checked into one repo. Submodules are kind of a pain. I wish they were represented better via the CLI.

jdavis703 10y ago

The only time I've wound up with a steaming mess was when I was first learning Git. I've been using it for 5 years now, and have done some pretty crazy things with it, and yet haven't screwed up the master branch since then. However to get to that point I had to read "Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development" (this was after royally fucking up and not wanting to get fired).

thomasvarney723 10y ago
Would you care to share that story?
- jdavis703 10y ago
  Basically Tuesday was the weekly deploy day. Master got screwed up from both a code perspective (incorrect conflict resolution), and then my fixes to rewrite history messed things up even more, blocking the release. Basically I didn't understand how Git worked (and me nor anyone else at my company apparently knew about reflogs).
  - skrebbel 10y ago
    And they'd fire you over that? Woa, horrid place.
    - jdavis703 10y ago
      Well I wasn't scared of being fired for that one mistake. But I didn't want to make it again, because after the second time you've just shown yourself to be an ass. Most places I've worked at are like "we allow you to make mistakes, but not the same mistake twice."
    - deleted 10y ago
      [deleted]

microcolonel 10y ago

"and of course I want undo in case I mess up and merge in case we both change the same file" That's what git reflog is for; and if you're paranoid you can set it up so it doesn't garbage collect as aggressively or at all.