Coding Blocks

This episode, we learn more about Git’s Index and compare it to other version control systems while Joe is throwing shade, Michael learns a new command, and Allen makes it gross.

The full show notes for this episode are available at https://www.codingblocks.net/episode194.

News

  • Want to help out the show? Leave us a review!
  • Ludum Dare is a bi-annual game jam that’s been running for over 20 years now. Jam #51 is coming up September 30th to October 3rd. (ldjam.com)
    • We previously talked about Ludum Dare in episode 146.

The Index

Meet the Middle Man

  • The index refers to the set of blobs and trees created when running a git add, when you “stage” files.
  • These trees and blobs are not a part of the repository yet!
    • If you were to unstage the changes using a reset, you’d have an orphaned blob(s) that would eventually get cleaned up.
  • The index is a staging area for your next commit.
  • The staging area allows you to build up your next commit in stages.
  • You can almost ignore the index by doing a git commit -a (but shouldn’t).
  • In Subversion, the next set of changes is always determined by looking at the differences in the current working tree.
  • In Git, the next set of changes is determined by looking at your index and comparing that to the latest HEAD.
    • git add allows you to make additional changes before executing your commit with things like git add --patch and git add --interactive parameters.
    • For Emacs fans out there, the author mentioned gitsum. (GitHub)

Taking the Index Further

  • The author mentions “Quilt!”, is it this? (man7.org)
    • The primary difference between Git and Quilt is Git only allows one patch to be constructed at a time.
  • Situation the author describes is: What if I had multiple changes I wanted to test independently with each other?
  • There isn’t anything built into Git to allow you to try out parallel sets of changes on the fly.
    • Multiple branches would allow you to try out different combinations and the index allows you to stage your changes in a series of commits, but you can’t do both at the same time.
    • To do this you’d need an index that allows for more than a single commit at a time.
    • Stacked Git is a tool that lets you prepare more than one index at a time. (stacked-git.github.io)
    • The author gives an example of using regular Git to do two commits by interactively selecting a patch.
    • Then, the author gives the example of how you’d have to go about disabling one set of changes to test the other set of changes. It’s not great … swapping between branches, cherry-picking changes, etc.
  • If you find yourself in this situation, definitely take a look at Stacked Git. Using Stacked Git, you are basically pushing and popping commits on a stack.

Resources we Like

Tip of the Week

  • Diffusion Bee is GUI for running Stable Diffusion on M1 macs. It’s got a one-click installer that you can get up and generating weird computer art in minutes … as long as you’re on a recent version of macOS and M1 hardware. (GitHub)
    • No M1 Mac? You can install the various packages you need to do it yourself, some assembly required! (assembly.ai)
  • Git Tower is a fresh take on Git UI that lets you drag-n-drop branches, undo changes, and manage conflicts. Give it a shot! (git-tower.com)
  • Git Kraken is the Gold Standard when it comes to Git UIs. It’s a rich, fully featured environment for managing all of your branches and changes. They are also the people behind the popular VS Code Extension GitLens (gitkraken.com)
  • GitHub CLI is an easy to use command line interface for interacting with GitHub. Reason 532 to love it … draft PR creation via gh pr create --draft ! (cli.github.com)
Direct download: coding-blocks-episode-194.mp3
Category:Software Development -- posted at: 8:01pm EDT

It’s time to understand the full power of Git’s rebase capabilities while Allen takes a call from Doc Brown, Michael is breaking stuff all day long, and Joe must be punished.

The full show notes for this episode are available at https://www.codingblocks.net/episode193.

News

  • Thanks for the review Itsamritchahal!
  • Ludum Dare is a bi-annual game jam that’s been running for over 20 years now. Jam #51 is coming up September 30th to October 3rd. (ldjam.com)
    • We previously talked about Ludum Dare in episode 146.

Branching and the power of rebase

  • Every branch you work in typically has one or more base commits, i.e. the commits the branch started from.
  • git branch shows the branches in your local repo.
  • git show-branch shows the branch ancestry in your local repo.
    • Reading the output from the bottom up takes you from oldest to newest history in the branches
    • Plus signs, are used to indicate commits on divergent branches from the one that’s currently checked out.
    • An asterisk, is used to indicate commits that happened on the current branch.
    • At the top of the output above the dashed line, the output shows the branches, the column and color that will identify their commits, and the label used when identifying their commits.
  • Consider an example repo where we have two branches, T and F, where T = Trunk and F = Feature and the commit history looks like this:
  • What we want to do is bring Feature up to date with what’s in Trunk, so bring T2T3, and T4 into F3.
    • In most source control systems, your only option here is to merge, which you can also do in Git, and should be done if this is a published branch where we don’t want to change history.
    • After a merge, the commit tree would look like this:
  • The F3' commit is essentially a “meta-commit” because it’s showing the work necessary to bring T4 and F3 together in the repository but contains no new changes from the working tree (assuming there were no merge conflicts to resolve, etc.)
    • If you would rather have your work in your Feature branch be directly based on the commits from Trunk rather than merge commits, you can do a git rebasebut you should only do this for local development.
    • The resulting branch would look like this:
  • You should only rebase local branches because you’re potentially rewriting commits and you should not change public history.
    • When doing the merge, the merge commit, F3' is an instruction on how to transform F3 + T4.
    • When doing the rebase, the commits are being rewritten, such that F1' is based on T4 as if that’s how it was originally written by the author.
  • Use rebase for local branches that don’t have other branches off it, otherwise use merge for anything else.

Interactive rebasing

  • git rebase will try to automatically do all the merging.
  • git rebase -i will allow you to handle every aspect of the rebase process.
    • pick – This is the default behavior when not using -i. The commit should be applied to its rewritten parent. If there are conflicts, you’re allowed to resolve them before continuing.
    • squash – Use this option when you want to combine the contents of a commit into the previous commit rather than keeping the commits separate. This is useful for when you want multiple commits to be rewritten as a single commit.
    • edit – This will stop the rebasing process at that commit and let you make any changes before doing a git rebase --continue. This allows you to make changes in the middle of the process, making it look like the edit was always there.
    • drop – Use when you want to remove a commit from the history as if it had never been committed. You can also remove the commit from the list or comment it out from the rebase file to get the same results. If there were any commits later that depended on the dropped commit, you will get merge conflicts.
  • Interactive gives you the ability to reshape your branch to how you wish you’d done it in the first place, such as reordering commits.

Resources we Like

Tip of the Week

  • Russian Circles is a rock band that makes gloomy, mid-tempo, instrumental music that’s perfect for coding. They just put out a new album and, much like the others, it’s great for coding to! (YouTube)
  • GitLens for Visual Studio Code is an open-source extension for Visual Studio Code that brings in a lot more information from your Git repository into your editor. (marketplace.visualstudio.com)
  • Configure Visual Studio Code as your Git editor. (coding.visualstudio.com)
  • JSON Crack is a website that makes it easy to “crack” JSON documents and view them hierarchically. Great for large docs. Thanks for the tip Thiyagu! (JsonCrack.com)
  • Handle is a Windows utility that you can use to see which process has a “handle” on your resource. Thanks for the tip Larry Weiss! (docs.microsoft.com)
  • Crunchy Data has made it so you can run PostgreSQL in the browser thanks to WASM. Technically very cool, and it’s a great way to learn Postgres. Thanks for the tip Mikerg! (Crunchy Data)
  • Divvy is a cool new window manager for macOS. It’s cool, modern, and much more powerful than the built in manager! Thanks for the tip jonasbn! (apps.apple.com)
Direct download: coding-blocks-episode-193.mp3
Category:Software Development -- posted at: 9:31pm EDT

1