5 ms·

This is exactly what I felt was missing as well. Git is the kind of "skill" you can only master on the job, doing lots of case studies, not just reading documen

by iib 5y ago

This is exactly what I felt was missing as well. Git is the kind of "skill" you can only master on the job, doing lots of case studies, not just reading documentation and tutorials. There are lots of other programs like that, GDB for example, each with it's own challenge of sythesizing case studies. I hope this kind of learning continues, not only with git, but across other programs as well.

dboreham 5y ago
This is a symptom of the extremely poor design of its user interface (conceptually, I mean, not how it looks), notwithstanding its origins in Linux royalty.
- wrycoder 5y ago
  The secret is that git is, first and foremost, an on-disk data structure (hereafter "git repo"). It's very well-defined and documented, which means that anyone can write a new tool that processes a git repo. Go for it!
  - ellyagg 5y ago
    Good idea, but I've already filled all available slots for working on projects with no upside for me or my company.
  - bsder 5y ago
    No. We had better solutions, but the combination of "FREE!" and "network effects" meant that the GitHub virus won and the Git host came along for the ride. Even Linus hates the way GitHub does things, but he can't do anything about it at this point except complain.
    - mkesper 5y ago
      The discussion is about the 'git' command itself, not about Github.
      - bsder 5y ago
        Except that we are talking about Github because something better than git can't exist because it also has to displace Github.
        rsfern 5y ago
        Shouldn’t it be feasible to build an interoperable version control system so you can still collaborate on GitHub?
        CRConrad 5y ago
        What's to displace; who "needs" GitHub, and why? Just stop using it and use git (or whatever you want to use in stead).
    - candu 5y ago
      This is not a compelling argument against GitHub (and, as others note, it doesn't really have anything to do with the article, nor does it really add anything to the discussion.) Why does Linus hate "the way GitHub does things"? Are you referring to this [1] (which, I'll note, is ambivalent on the value of GitHub as a whole, and is only negative specifically on the matter of GitHub merges?) Or is there some other argument here that we're all supposed to be familiar with? What are these "better solutions"? Where are they? Where can I find and use them? Are they, in fact, better thought-out and more usable than GitHub? How can I test your assertions here? [1] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5...
      - bsder 5y ago
        We had Monotone, Darcs and others. We still have Mercurial. They all coexisted and were being developed. Even Github wasn't a big deal in the beginning and was just one of many providers who were all bootstrapped. However, once GitHub hit the field with $100 million in VC cash it squashed further development cold--bootstrapping and quality doesn't matter much against someone burning VC cash against you. Distributed source control is now in a path dependent local minimum and we are stuck with git because we are stuck with GitHub--better is no longer sufficient to break the logjam. Until Microsoft turns the screws enough this will all remain status quo.
- deleted 5y ago
  [deleted]
- u801e 5y ago
  Compared to what came before it, I really don't see how the interface is any less intuitive or documented compared to svn or cvs. For example, see the sections for the checkout command for svn[1] and cvs[2]. And then there's the man page[3] for the git-checkout command. The git documentation is a bit more detailed. [1] https://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.checkout.html https://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.checkout.h... [2] https://linux.die.net/man/1/cvs https://linux.die.net/man/1/cvs [3] https://git-scm.com/docs/git-checkout https://git-scm.com/docs/git-checkout
  - kevin_thibedeau 5y ago
    Git checkout is overloaded with too many behaviors. If it was naturally intuitive they wouldn't have needed to add the restore command. A better comparison would be Mercurial which has a much more coherent command interface.
    - u801e 5y ago
      Given the widespread use of git now, it's probably the first VCS that people are exposed to. But, for several years after it was released, it was the first distributed VCS that people used (if they hadn't had a chance to work with other DVSs like mercurial or bazaar). So, it's likely most people at that time were used to using svn or cvs. As for overloading the checkout command, the git man page lists the following 1. checkout a branch 2. checkout and create a new branch (combining git checkout and git branch) 3. checkout a path at a certain commit In contrast, the svn co/checkout command has the following options 1. Checkout a directory 2. Checkout a file 3. Checkout a directory or file at a certain revision Which really isn't that different. Given svn's concept of branches really being copies of the repository, one would switch branches by just checking out a different branch by using the switch command. In this case, I think git's interface is better since you don't need a different command to just change between branches.
  - dboreham 5y ago
    I'm speaking about the concepts that underly the interface, not the details of options and so on. svn was orders of magnitude better: you checked out a repo, you made local changes, you got to see the changes you made before committing, you committed changes, unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling. That's it. Now, I admit that much of the conceptual complexity with git is to do with it being a decentralized system. svn was not. However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity.

by iib 5y ago

dboreham 5y ago

This is a symptom of the extremely poor design of its user interface (conceptually, I mean, not how it looks), notwithstanding its origins in Linux royalty.

wrycoder 5y ago
The secret is that git is, first and foremost, an on-disk data structure (hereafter "git repo"). It's very well-defined and documented, which means that anyone can write a new tool that processes a git repo. Go for it!
- ellyagg 5y ago
  Good idea, but I've already filled all available slots for working on projects with no upside for me or my company.
- bsder 5y ago
  No. We had better solutions, but the combination of "FREE!" and "network effects" meant that the GitHub virus won and the Git host came along for the ride. Even Linus hates the way GitHub does things, but he can't do anything about it at this point except complain.
  - mkesper 5y ago
    The discussion is about the 'git' command itself, not about Github.
    - bsder 5y ago
      Except that we are talking about Github because something better than git can't exist because it also has to displace Github.
      - rsfern 5y ago
        Shouldn’t it be feasible to build an interoperable version control system so you can still collaborate on GitHub?
      - CRConrad 5y ago
        What's to displace; who "needs" GitHub, and why? Just stop using it and use git (or whatever you want to use in stead).
  - candu 5y ago
    This is not a compelling argument against GitHub (and, as others note, it doesn't really have anything to do with the article, nor does it really add anything to the discussion.) Why does Linus hate "the way GitHub does things"? Are you referring to this [1] (which, I'll note, is ambivalent on the value of GitHub as a whole, and is only negative specifically on the matter of GitHub merges?) Or is there some other argument here that we're all supposed to be familiar with? What are these "better solutions"? Where are they? Where can I find and use them? Are they, in fact, better thought-out and more usable than GitHub? How can I test your assertions here? [1] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5...
    - bsder 5y ago
      We had Monotone, Darcs and others. We still have Mercurial. They all coexisted and were being developed. Even Github wasn't a big deal in the beginning and was just one of many providers who were all bootstrapped. However, once GitHub hit the field with $100 million in VC cash it squashed further development cold--bootstrapping and quality doesn't matter much against someone burning VC cash against you. Distributed source control is now in a path dependent local minimum and we are stuck with git because we are stuck with GitHub--better is no longer sufficient to break the logjam. Until Microsoft turns the screws enough this will all remain status quo.
deleted 5y ago
[deleted]
u801e 5y ago
Compared to what came before it, I really don't see how the interface is any less intuitive or documented compared to svn or cvs. For example, see the sections for the checkout command for svn[1] and cvs[2]. And then there's the man page[3] for the git-checkout command. The git documentation is a bit more detailed. [1] https://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.checkout.html https://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.checkout.h... [2] https://linux.die.net/man/1/cvs https://linux.die.net/man/1/cvs [3] https://git-scm.com/docs/git-checkout https://git-scm.com/docs/git-checkout
- kevin_thibedeau 5y ago
  Git checkout is overloaded with too many behaviors. If it was naturally intuitive they wouldn't have needed to add the restore command. A better comparison would be Mercurial which has a much more coherent command interface.
  - u801e 5y ago
    Given the widespread use of git now, it's probably the first VCS that people are exposed to. But, for several years after it was released, it was the first distributed VCS that people used (if they hadn't had a chance to work with other DVSs like mercurial or bazaar). So, it's likely most people at that time were used to using svn or cvs. As for overloading the checkout command, the git man page lists the following 1. checkout a branch 2. checkout and create a new branch (combining git checkout and git branch) 3. checkout a path at a certain commit In contrast, the svn co/checkout command has the following options 1. Checkout a directory 2. Checkout a file 3. Checkout a directory or file at a certain revision Which really isn't that different. Given svn's concept of branches really being copies of the repository, one would switch branches by just checking out a different branch by using the switch command. In this case, I think git's interface is better since you don't need a different command to just change between branches.
- dboreham 5y ago
  I'm speaking about the concepts that underly the interface, not the details of options and so on. svn was orders of magnitude better: you checked out a repo, you made local changes, you got to see the changes you made before committing, you committed changes, unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling. That's it. Now, I admit that much of the conceptual complexity with git is to do with it being a decentralized system. svn was not. However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity.