7 ms·

I got pretty fed up with learning got from the internet when I had too (about 8 years ago). Every resource I could find was written in a way that only people th

I got pretty fed up with learning got from the internet when I had too (about 8 years ago). Every resource I could find was written in a way that only people that already knew could really understand. Now, that I finally feel good enough, that I can rely on what I know and finally in position to mentor others, I made what I feel was missing, a set of sandbox git repository challenges, with only real life examples [1] I met in professional repos. I hope the dark age of git education passes soon (and is already fading). [1]: https://github.com/operatorequals/git-course https://github.com/operatorequals/git-course

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...
  - 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.
jerf 5y ago
I believe this is generally true, but git happens to sit in a nexus where it is particularly true: You can't hand someone the solution to a problem they've never had. I have a git training I developed for work that focuses not on telling everyone what the solutions to their problems are, but walking them into those problems, getting into detached head, getting into branching and rebasing problems, and then explaining how to get back out of them. I've gotten generally positive feedback from this. If nothing else, at the very least it convinces them that when they see the "detached head" message, they can come get help and I'll be very sympathetic to what is going on, because I told them up front that I expect this sort of thing to happen and it doesn't mean they're bad people for getting into this state, and we can at least have a sane conversation about what they did to get there and what they want to happen. It's probably particularly hard to try to tell people the solutions to problems they've never had when they also don't even know what's going on around them and what a problem even is.

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...
- 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.

jerf 5y ago

I believe this is generally true, but git happens to sit in a nexus where it is particularly true: You can't hand someone the solution to a problem they've never had. I have a git training I developed for work that focuses not on telling everyone what the solutions to their problems are, but walking them into those problems, getting into detached head, getting into branching and rebasing problems, and then explaining how to get back out of them. I've gotten generally positive feedback from this. If nothing else, at the very least it convinces them that when they see the "detached head" message, they can come get help and I'll be very sympathetic to what is going on, because I told them up front that I expect this sort of thing to happen and it doesn't mean they're bad people for getting into this state, and we can at least have a sane conversation about what they did to get there and what they want to happen. It's probably particularly hard to try to tell people the solutions to problems they've never had when they also don't even know what's going on around them and what a problem even is.