Posts from 22 December 2017
-
There are topics we research once in a while to confirm that they're still bad ideas.
I jokingly recall that my dad tries cooking eggplant once every two years to see if he still dislikes it. The last time I was around, we both ate a single slice of a rather appealing looking Eggplant Parmesan, looked at each other, and threw the rest of the tray away.
Today, that mistake is
git-submodules. It makes sense that we'd want to have code that can be used together but that is upgraded at different rates! And, in all honesty, there are plenty of solutions for this kind of problem that don't demand submodules. A typical ruby solution would be to build a gem and either publish it on rubygems, or point the Gemfile to a known git repo; I imagine most other packaging systems offer a similar solution.Back at Demyst, we used a monorepo, and while I can't decide offhand if that was the right decision, it was skill-appropriate for our situation, and we made it work.
For a time we considered using submodules, but our CTO waved me off and so I didn't do more than some perfunctory research into them at the time.
Today, I thought I'd look at them again, and (as you do), I ended up reading git-scm.
(For context, I'm also knees-deep in writing the book at the moment.)
Looking at the description of submodules, there's … nothing at all worrying here. As one person on HackerNews described it, "so the problem with submodules is that they don't work if you don't use them right."
While writing the book recently, I wondered how to explain to readers how to get over the biggest hump in algebra. And it occurred to me: most problems with git are the same problems people face when learning algebra.
Consider this: algebra is a way of describing highly abstract situations using symbolic representations. We wish to accomplish some task, so we convert the relevant information to symbols, then manipulate those symbols until we recognize that we've achieved a result. We then translate the result back into the language of the problem.
Students who never grasp algebra tend to view it as a collection of recipes. They find a formula that seems to fit their situation, plug numbers in, manipulate by rote, and hope for the best.
I think we've all met developers who do this with git. (Some of us are these developers.) The trouble in both situations is that we don't know what we're trying to accomplish; the canonical "developer who doesn't understand git" treats commits as a secretary treats saving in Microsoft Word: something to be done periodically to ensure you don't lose work.
git add .; git commit -m "Update". All that fits in their model of the world is "this is a way to save my progress and make it available to other developers."Which can be fine, but it means that in a typical repo the value of using git at all can be lost in the mix1.
For math students and developers, the solutions are probably similar. Motivate the core abstractions, then practice applying them until a) they can see that the abstractions relate to their real-world problems and b) the actions they take mean things and aren't just arcane spells.
The syntax of algebra, and the syntax of git, can be confused as the goal itself, when in truth the syntax is a means; the goal itself is abstract, and without having a pre-existing understanding of what you're trying to accomplish, both skills will always seem like magic.
-
I for one am a huge fan of patch mode. Even when I'm editing files that span concerns, I'll use
git add -pto triage the files into multiple thematically related commits so that when it comes time to review the history of the codebase, I can remember why I did that particular stupid thing. ↩
-