tl;dr:“Job control” is a set of commands for seeing which processes are running in a terminal and moving processes between 3 states: jobs in the foreground, in the background and jobs stopped. Julia asked her network for reasons people use job control, sharing responses here.
tl;dr:Julia discusses various strategies she’s put into place when facing an unclear error messages in Git. “I’m going to go through a bunch of Git’s error messages, list a few things that I think are confusing about them for each one, and talk about what I do when I’m confused by the message.”
tl;dr:(1) Fear can make you overly conservative as a programmer, afraid to make important changes. This leads to worse software in the long run. (2) Better tools and processes reduce fear to make changes e.g. version control, automated testing. (3) How an organization reacts to mistakes is critical i.e. blameless postmortems. (4) Some fears spread to others if not addressed. (5) Fear creates "local maximums" - it prevents you from making big improvements and keeps you stuck in a suboptimal state.
tl;dr:“I’ve been thinking more about what the term “current branch” means in git and it’s a little weirder than I thought.” Julia shares 4 possible definitions and scenarios for each.
tl;dr:Julia ran a poll asking people how confident they were that they understood how HEAD works in Git. The results were a little surprising... people were unconfident about their understanding. “Usually when people say that a topic is confusing when I think it’s not, the reason is that there’s actually some hidden complexity that I wasn’t considering. And after some follow up conversations, it turned out that HEAD actually was a bit more complicated than I’d appreciated!”
tl;dr:“I always wish that command line tools came with data about how popular their various options are, like: (1) “basically nobody uses this one”. (2) “80% of people use this, probably take a look”. (3) “this one has 6 possible values but people only really use these 2 in practice.” Julia asked about people’s favourite git config options and shares the responses.
tl;dr:"One of the most common problems I see folks struggling with in Git is when a local branch (like "main") and a remote branch (maybe also called "main") have diverged. There are two things that make this hard: (1) If you’re not used to interpreting git’s error messages, it’s nontrivial to realize that your main has diverged from the remote. (2) There's no single clear way to handle it - it depends on the situation and your git workflow." Julia discusses what to do.
tl;dr:Julia provides a short explanation of each part of your .git directory helps develop your mental model and better understanding: (1) How merges and rebases work and how they can go wrong. (2) How exactly your colleagues are using git, and what guidelines you should be following to work with them successfully. (3) How pushing / pulling code from other repositories works. (4) how to handle merge conflicts.
tl;dr:"I’ve been extremely slowly trying to figure how to explain every core concept in Git (commits! branches! remotes! the staging area!) and commits have been surprisingly tricky. Understanding how git commits are implemented feels pretty straightforward to me, but it’s been much harder to figure out how other people think about commits. So like I’ve been doing a lot recently, I went on Mastodon and started asking some questions."
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!"