A heat map for your git repo š„
This Python-based tool scans through your git log
and generates a heat map like the one below from the cpython repo, which highlights the files that Guido van Rossum changed the most.
This Python-based tool scans through your git log
and generates a heat map like the one below from the cpython repo, which highlights the files that Guido van Rossum changed the most.
If youāre better with words than you are with shapes, this git guide by Zach Musgrave may help you get out of the āI memorized N git commands but I have no idea how any of this worksā phase.
Hereās how Zach describes it:
The git commit graph and its relationship to common git workflows explained using simple English and easy to understand diagrams. Also some jokes.
Distributed, offline-first bug tracker embedded in git, with bridges
I love the idea of having your bug repo right there inside your code repo. The terminal UI is a nice touch!
An interesting idea from Gustav Westlingā¦
One of the things that I like to do in my projects, is to make the git history as linear as possible.
Usually this means to rebase commits onto the main branch, but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project.
Today Iām taking this one step further, and Iām introducing a new concept: extremely linear git history.
With our extremely linear history, the first commit in a repo hash a hash that starts with
0000000
, the second commit is0000001
, the third is0000002
, and so on!
How he accomplishes this is perhaps even more interesting (and hacky!)
I recently discovered an awesome tool called Coolify that calls itself an open-source Netlify or Heroku alternative that can be self-hosted. Gave it a whirl for my own personal projects and loved it, so I thought Iād share.
This is a solid primer on git rebase and the many ways itās useful.
In Git, a rebase is a very versatile and useful tool to rework commits. Use it to achieve a workflow with high-quality changes proposed in high-quality commits and merge requests. It makes your developers and reviewers more efficient. Code reviews and debugging also become easier and more effective.
Hereās the motivation behind this Rust-based TUI:
I do most of my git work in a terminal but I frequently found myself using git GUIs for some use-cases like: index, commit, diff, stash, blame and log.
Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable.
GitUI provides you with the user experience and comfort of a git GUI but right in your terminal while being portable, fast, free and open source.
This nifty little web app lets you tour the history of a file on GitHub. The coolest part about it is that you donāt have to download or install anything! Just change the github.com
part of the URL with github.githistory.xyz
and youāre in action!
Ben Congdon explains why heās enthusiastic about stacked PRs (and how they differ from stacked commits). We discussed many of these benefits in our conversation with the Graphite guys, but thatās just one way of going about the practice. Ben also lists out a few helpers tools for going about it.
Simply run git log --full-history --date=short --pretty=format:"%ad,%an" > gitlog.csv
and upload the resulting file. Hereās what changelog.comās looks like (10+ commits only to keep it tight) š
Provides interactive git add
, git log
(š below), git diff
, and a bunch more. Powered by fzf
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:
rsync
/Dropbox/etcAnd 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 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 overgit 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
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, splittinggit 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.