5 ms·

Git Exercises

125 points by Aga 9y ago

chrisweekly 9y ago
+1 for well-written FAQs
yebyen 9y ago
Site is evidently crumbling under load... getting some 50x responses from the load balancer. (edit: seems ok now?)
- m3kw9 9y ago
  Still down
- insomniacity 9y ago
  Now getting TLS error!
da_chicken 9y ago
This is actually pretty well done, but I can't help but feel like the number of articles and documents trying to explain or teach git is a sign that the tool just has usability problems. Maybe I'm misremembering, but I don't remember people having so much trouble with svn. With rcs and cvs, sure, and it was mainly stuff with breaking locks, moving files, and other BS that were part of the bad design. With svn I remember the problems being: setting up the daemon (https vs svnserve+ssh), fixing a wedged Berkeley DB when that was still a thing, and getting hook scripts working right cross-platform. With git, the common problem seems to be: "what command am I even supposed to use here?" and "I broke it somehow and I don't know how to fix it." If the number of articles about it ever seemed to go down I might say, "Oh, it's just growing pains for new users," but they still seem to be out there constantly. Why is everybody still having trouble learning to use git? Note to the zealots: This isn't to say git is bad, anymore than vi/vim is bad for having it's own arcane interface that users have complained about and struggled with for decades. Lots of terrific software carries burdens like a terrible interface, or an onerous configuration, or a lack of documentation. That doesn't mean we can't be critical.
- yebyen 9y ago
  What is a simple (or should I say easy?) workflow that allows three (or three hundred) people to work on the same codebase? I'd challenge that there isn't one, and that sometimes a complex problems has a complex solution. I think the fact is that many people have worked with git on their own, and then they may think that they know git. Many of those people then go on to work on a small project with hardly any devs working concurrently on the same code, but just enough to run into problems they didn't have before. This way you get the brightest of those people to start to understand that no, unless you've worked on a Git project with a team and handled the issues that comes along with that experience, you don't actually know Git yet. Unfortunately with smaller teams, those people often learn Git so well (and, to be fair, "so well" is only marginally better than the person who works on Git by themselves, but getting to know it that well is still a substantial barrier, because git merge conflicts are pain, and pain is naturally avoided, but one can only learn to solve a problem by rote, ... by rote, or by repeating the solution.) ...that the rest of their team often doesn't have to learn the hard parts at all. That person then "handles the git issues." You don't really need to get Mad Git Skillz if you don't have a need to deal with those issues, and if your company's core competency is solving git merge conflicts, then you know you have a problem... anyway... As team size approaches "the Linux kernel" or similarly byzantine and gargantuan project scope, the frequency of having "those issues" increases and the absolute number of "git people" needed to handle them obviously goes up. Maybe if you're lucky, the proportion of people who know Git well enough to solve the hard problems also goes up, so as a member of the team, your frequency of encountering a Git Person who might impart some Git Wisdom onto you will also go up. Git isn't only good for teams that need to solve hard problems like OS kernels though. Some teams don't ever need to solve especially hard problems (not to belittle those teams, and notwithstanding that "complex" and "hard" can be separate, and the domain of hard problems is vast and many teams that do solve "hard" problems still don't need to solve hard git problems.) But they still know they need Git to do their jobs. Those teams may learn enough Git, then dodge the bullet and never "get a Git person" and they are absolutely still really using Git productively. They're using Git to solve a problem that it solves, they're just not using Git to solve hard problems. They may even get really good at avoiding encountering those hard problems before they ever need to spend the time to learn to solve them, from repeated exposure to let's call them "merge traumas." And you will get successful teams on both ends of the spectrum. Not to stray too far from the topic at hand, this site and the exercises look great. I like the mix of easy and hard problems. I like that the word "rebase" is nowhere to be found on the front page, but as a person who knows how to use rebase (and struggles to explain it to my team sometimes) it was very easy to find the exercise that will teach it, and see that it is not an especially difficult example at all. The fact that Git is successful I think can be attributed strongly to the fact that Git can make solving some very hard problems possible and with great ease, when you have become "a git person."
deleted 9y ago
[deleted]

Git Exercises

125 points by Aga 9y ago

chrisweekly 9y ago

+1 for well-written FAQs

yebyen 9y ago

Site is evidently crumbling under load... getting some 50x responses from the load balancer. (edit: seems ok now?)

m3kw9 9y ago
Still down
insomniacity 9y ago
Now getting TLS error!

da_chicken 9y ago

This is actually pretty well done, but I can't help but feel like the number of articles and documents trying to explain or teach git is a sign that the tool just has usability problems. Maybe I'm misremembering, but I don't remember people having so much trouble with svn. With rcs and cvs, sure, and it was mainly stuff with breaking locks, moving files, and other BS that were part of the bad design. With svn I remember the problems being: setting up the daemon (https vs svnserve+ssh), fixing a wedged Berkeley DB when that was still a thing, and getting hook scripts working right cross-platform. With git, the common problem seems to be: "what command am I even supposed to use here?" and "I broke it somehow and I don't know how to fix it." If the number of articles about it ever seemed to go down I might say, "Oh, it's just growing pains for new users," but they still seem to be out there constantly. Why is everybody still having trouble learning to use git? Note to the zealots: This isn't to say git is bad, anymore than vi/vim is bad for having it's own arcane interface that users have complained about and struggled with for decades. Lots of terrific software carries burdens like a terrible interface, or an onerous configuration, or a lack of documentation. That doesn't mean we can't be critical.

yebyen 9y ago
What is a simple (or should I say easy?) workflow that allows three (or three hundred) people to work on the same codebase? I'd challenge that there isn't one, and that sometimes a complex problems has a complex solution. I think the fact is that many people have worked with git on their own, and then they may think that they know git. Many of those people then go on to work on a small project with hardly any devs working concurrently on the same code, but just enough to run into problems they didn't have before. This way you get the brightest of those people to start to understand that no, unless you've worked on a Git project with a team and handled the issues that comes along with that experience, you don't actually know Git yet. Unfortunately with smaller teams, those people often learn Git so well (and, to be fair, "so well" is only marginally better than the person who works on Git by themselves, but getting to know it that well is still a substantial barrier, because git merge conflicts are pain, and pain is naturally avoided, but one can only learn to solve a problem by rote, ... by rote, or by repeating the solution.) ...that the rest of their team often doesn't have to learn the hard parts at all. That person then "handles the git issues." You don't really need to get Mad Git Skillz if you don't have a need to deal with those issues, and if your company's core competency is solving git merge conflicts, then you know you have a problem... anyway... As team size approaches "the Linux kernel" or similarly byzantine and gargantuan project scope, the frequency of having "those issues" increases and the absolute number of "git people" needed to handle them obviously goes up. Maybe if you're lucky, the proportion of people who know Git well enough to solve the hard problems also goes up, so as a member of the team, your frequency of encountering a Git Person who might impart some Git Wisdom onto you will also go up. Git isn't only good for teams that need to solve hard problems like OS kernels though. Some teams don't ever need to solve especially hard problems (not to belittle those teams, and notwithstanding that "complex" and "hard" can be separate, and the domain of hard problems is vast and many teams that do solve "hard" problems still don't need to solve hard git problems.) But they still know they need Git to do their jobs. Those teams may learn enough Git, then dodge the bullet and never "get a Git person" and they are absolutely still really using Git productively. They're using Git to solve a problem that it solves, they're just not using Git to solve hard problems. They may even get really good at avoiding encountering those hard problems before they ever need to spend the time to learn to solve them, from repeated exposure to let's call them "merge traumas." And you will get successful teams on both ends of the spectrum. Not to stray too far from the topic at hand, this site and the exercises look great. I like the mix of easy and hard problems. I like that the word "rebase" is nowhere to be found on the front page, but as a person who knows how to use rebase (and struggles to explain it to my team sometimes) it was very easy to find the exercise that will teach it, and see that it is not an especially difficult example at all. The fact that Git is successful I think can be attributed strongly to the fact that Git can make solving some very hard problems possible and with great ease, when you have become "a git person."

deleted 9y ago

[deleted]