tl;dr:"The main reason I wanted to make this was to give folks some intuition for how git works under the hood. After all, git commits really are very similar to folders – every Git commit contains a directory listing of the files in it, and that directory can have subdirectories, etc... It’s just that git commits aren’t actually implemented as folders to save disk space. So in git-commit-folders, every commit is actually a folder, and if you want to explore your old commits, you can do it just by exploring the filesystem!"
tl;dr:Julia discusses an intuitive mental model that many people have, how git actually represents branches internally i.e. branches are a pointer to a commit, how the “intuitive model” and the real way it works are actually pretty closely related and some limits of the intuitive model and why it might cause problems.
tl;dr:"One of my biggest problems is that after almost 15 years of using git, I’ve become very used to git’s idiosyncrasies and it’s easy for me to forget what’s confusing about it." Julia asked folks "what git jargon do you find confusing? thinking of writing a blog post that explains some of git’s weirder terminology: “detached HEAD state”, “fast-forward”, “index/staging area/staged”, “ahead of ‘origin/main’ by 1 commit”, etc."
tl;dr:“None of these things feel super surprising in retrospect, but I hadn’t thought about them clearly before. The facts are: (1) The “index”, “staging area” and “–cached” are all the same thing. (2) The stash is a bunch of commits. (3) Not all references are branches or tags. (4) Merge commits aren’t empty.” Julia discusses each in detail.
tl;dr:When you face a topic that’s hard to understand, you are likely not alone. Julia talks about how to move folks from the "I really don't get it" column, to the "okay, I can mostly deal with this” column using some of the following tricks: sharing useful tools, sharing references, telling a chronological story of what happens on your computer, turning a big list into a small list of the things you actually use, showing the hidden things, and demoing the tool. Julia gives examples of how these have made learning for her easier.
tl;dr:Julia explores the inner workings of git, specifically how it stores files in the .git/objects directory. Through Python programs, Julia investigates the location of specific files and their older versions discovering "content addressed storage," where the filename is the hash of the file's content. The article also demystifies the encoding process, showing that files are zlib compressed, and emphasizes that git stores complete files, not just the differences.
tl;dr:Various strategies and resources to help people become more comfortable with using the command line. It identifies three main areas to focus on: reducing risks, finding motivation, and utilizing resources. To reduce risks, the article suggests regular backups, using tools, avoiding wildcards, and building --dry-run options into scripts. Motivations might include finding a "killer command line app" or being inspired by command line wizardry. Resources include utilizing tools like explainshell, fzf, and oh-my-zsh, and seeking help from experienced friends or co-workers. Cheat sheets, aliases, and workshops are also mentioned as helpful aids.
tl;dr:Julia discusses various strategies and tactics to engage with comments and feedback on her writing, especially in the context of technical blogging. Key points include: (1) Talk about facts leads to fact-based comments and discussions. (2) Sharing personal stories encourages good discussions and helps in understanding the context and different perspectives. (3) Ask technical questions or mentioning uncertainties invites answers and makes the comments section more valuable. And more.
tl;dr:(1) You need to be original. (2) You need to be an expert. (3) Posts need to be 100% correct. (4) Writing boring posts is bad. (5) You need to explain every concept. (6) Page views matter. (7) More material is always better. (8) Everyone should blog.
tl;dr:“I want to talk about what’s appealing to me about build systems, why I still don’t use them, and why I find it frustrating that some frontend Javascript libraries require that you use a build system.”