HUBFS is a file system for GitHub and Git. Git repositories and their contents are represented as regular directories and files and are accessible by any application, without the application having any knowledge that it is really accessing a remote Git repository. The repositories are writable and allow editing files and running build operations.

So if you hubfs mnt (on macOS/Linux), it will set up a file hierarchy inside /mnt that follows this pattern: / owner / repository / ref / path. Cool idea! It is affected by GitHub’s API rate limiting and I’m not sure if/how it syncs (commits) back to the remote repos…

Jujutsu (jj at your CLI) combines features from popular distributed version controls systems (Git, Mercurial, Darcs) with features not found in any of them, such as:

• working-copy-as-commit
• undo functionality
• automatic rebase
• safe replication via rsync/Dropbox/etc

And since it’s Git-compatible, adoption should be a breeze.

Jujutsu has two backends. One of them is a Git backend (the other is a native one). This lets you use Jujutsu as an alternative interface to Git. The commits you create will look like regular Git commits. You can always switch back to Git.

I’ve often wondered what will come next after Git. I’m not saying this is that thing, but it’s cool to see people working on the problem.

This week we’re joined by Annie Sexton, UX Engineer at Render, to talk about her blog post titled Git Organized: A Better Git Flow that made the internet explode when she suggested using reset instead of rebase for a better git flow. On this show we talk about the git flow she suggests and why, how this flow works for her when she’s hacking on the Render codebase (and when she uses it), the good and the bad of Git, and we also talked about the cognitive load of Git commits as you work.

This is just one of Charm’s various open source CLI projects.

Imagine this: you’ve been paged to investigate a production incident, and after some digging, you identify the commit with the breaking code. You decide to revert the change:

git revert 1a2b3c

Unfortunately, in doing so, a new bug is introduced! As it turns out, hidden in that old “broken” commit was some code that another part of the app depended upon, and when you reverted those lines, it left the site once again in a broken state. 🙃 Oh dear.

How can situations like this be avoided? To answer this question, we first need to examine how these types of commits come to be.

If you’ve never heard of or used git reset… this article is a must-read.

If you ever get into an “oh snap!” situation where you think you just lost days of work, checkout a dura branch and recover.

Without dura, you use Ctrl-Z in your editor to get back to a good state. That’s so 2021. Computers crash and Ctrl-Z only works on files independently. Dura snapshots changes across the entire repository as-you-go, so you can revert to “4 hours ago” instead of “hit Ctrl-Z like 40 times or whatever”. Finally, some sanity.

This sounds a lot like how Fossil works out of the box, except maybe even more paranoid because Fossil will propagate every commit whereas Dura propagates all changes even before they’re committed.

Eric Gregory asks (and answers) himself a question on The New Stack:

For years now, blogs, webinars and white papers have opined that GitOps is the Next Big Thing, yet here a respected voice in the field is saying to tread carefully. So what gives? Do we need to pump the brakes? Is GitOps just a lot of unwarranted hype? Or is there a missing piece of the puzzle here? As in so many things, the answer is: It’s complicated. GitOps can be transformative for some teams, but it’s not a one-size-fits-all solution.

This essay from Mary Rose Cook explains how Git works. Who should read this? Anyone who wants a deeper understanding of Git.

The essay assumes you understand Git well enough to use it to version control your projects. It focuses on the graph structure that underpins Git and the way the properties of this graph dictate Git’s behavior. Looking at fundamentals, you build your mental model on the truth rather than on hypotheses constructed from evidence gathered while experimenting with the API. This truer model gives you a better understanding of what Git has done, what it is doing, and what it will do.

(If you’d rather absorb the same information as a talk, you can watch this video instead.)

How much faster is it? See Timing. If the branch is currently checked out, then 10x is a reasonable estimate. If the branch is not checked out, then it’s even faster.

Is performance the only added feature? git move also offers several other quality-of-life improvements over git rebase. For example, it can move entire subtrees, not just branches. See the git move documentation for more information.

git move is part of the git-branchless suite. Cool stuff.

git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Very cool Marcus, very cool!

…let’s say that my code lives in $HOME/work and my personal code lives in $HOME/projects. You can do something like this

[user]
  email = user@example.com
  name = User
  signingkey = ABC123
[commit]
  gpgSign = true
[includeIf "gitdir:~/work/"]
  path = ~/.work.gitconfig

This week, Richard Hipp returns to catch us up on all things SQLite, his single file webserver written in C called Althttpd, and Fossil – the source code manager he wrote and uses to manage SQLite development instead of Git.

in version 2.23 of git, two new commands have been introduced to replace the old git checkout (git checkout is still available, but people new to git should start with these ones preferably). As you would expect, they basically each implement one of the two behaviors described previously, splitting git checkout in two.

TIL!

HOW HAVE I NOT HEARD OF GIT WORK TREES??? WHAT THE EFF. They are so incredible. You have to check them out!!! In this video I go over them briefly, assuming you are smart enough to understand them, and also show you my workflow with vim! Its fantastic!

Commit groups sounds interesting to me. Anyone reading this familiar with Git innards? Is this doable?

You know the “group” facility of vector graphics programs? You draw a couple of shapes, you group them together, and then you can apply transformations to the entire group at once, operating on it as if it were an atomic thing. But when need arises, you can “ungroup” it and look deeper.

I’d love to see that same idea applied to Git commits. In Git, a commit group might just be a named and annotated range of commits: feature-a might be the same as 5d64b71..3db02d3. Every Git command that currently accepts commit ranges could accept group names. I envision groups to have descriptions, so that git log, git blame, etc could take –grouped or –ungrouped options and act appropriately.

Sad but true: Git is simply too hard. One thing driving said truth is that undoing things often requires jumping through obscure hoops. Here’s what Waleed Khan has to say on the matter:

Well, it’s not that it’s too easy to lose your data — but rather, that it’s too difficult to recover it. For each operation you want to recover from, there’s a different “magic” incantation to undo it. All the data is still there in principle, but it’s not accessible to many in practice.

Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes.

To address this, Waleed created git undo as part of his git-branchless suite of tools.

LJ Miranda:

When I first saw “Avengers: Endgame” in theaters, I noticed that their time travel rule is quite similar to the Git branching model. Referred to as the time heist, our heroes travelled through time to recover the stones…

I had to truncate that pull quote to avoid Avengers spoilers. If you’ve seen the movie (or don’t care about getting spoiled) there’s some good Git knowledge to be gained from this analogy.

Chris Manson goes into detail about the benefits of a clean git history and describes some tips and tricks that really help you clean up your branches and Pull Requests.

Any git repository may contain tons of information about commits, contributors, and files. Extracting this information is not always trivial, mostly because there are a gadzillion options to a gadzillion git commands – I don’t think there is a single person alive who knows them all. Probably not even Linus Torvalds himself :).

A handy shell script to help you undo all the things (commits, pushes, pulls, you name it).

Here is an example to help you understand the importance of cherry-picking. Suppose you have made several commits in a branch, but you realize it’s the wrong branch! What do you do now? Either you repeat all your changes in the correct branch and make a fresh commit, or you merge the branch into the correct branch. Wait, the former is too tedious, and you may not want to do the latter. So, is there a way? Yes, Git’s got you covered.

I’m a pretty big fan of cherry-pick, too. I don’t use it often, but every time I do… 👨‍🍳💋

Imagine a world where Git and MySQL got together and had a baby. They would name that baby, Dolt.

Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files, commit your changes, push them to a remote, or merge your teammate’s changes.

All the commands you know for Git work exactly the same for Dolt. Git versions files, Dolt versions tables.

The authors also created DoltHub where you can host and share your Dolt databases.

Sometimes you need to communicate changes to other developers on your project. In a small team, a Slack message works okay, but in larger teams and distributed organizations (such as open source projects), reaching everyone can be a pain.

Logging this because it’s an interesting idea, but I’m not sure if it’s a good idea. Is this a good idea?

Martin Heinz shares some of his favorite git features: word diff, auto-correct, plugins, and commit signing.

Git is the perfect technology to maximize cheat sheet value. It has a large surface area of commands and requires some esoteric combos to get things done. (Why is there still not a git undo?)