Git tricks

1 Learning Git

See the fastai masterclass for many more helpful tips/links/scripts/recommendations. Learn Git Branching explains the mechanics in a friendly fashion. Steve Bennett’s 10 things I hate about Git is also useful.

Mark Dominus’ master class:

• The Universe of Discourse: Things I wish everyone knew about Git (Part I)
• The Universe of Discourse: Things I wish everyone knew about Git (Part II)

2 Tips

Universally acclaimed classic: git tips.

3 Handy Git config

git config --global core.editor "code-insiders --wait"  # insiders

echo .DS_Store >> .gitignore_global
git config --global core.excludesfile $HOME/.gitignore_global

4 Handy git commands

git diff --name-only --diff-filter=U | xargs git checkout --theirs --

echo "alias git_theirs 'git diff --name-only --diff-filter=U | xargs git checkout --theirs --'" >  ~/.config/fish/conf.d/git_theirs.fish
echo "alias git_ours   'git diff --name-only --diff-filter=U | xargs git checkout --ours   --'" >> ~/.config/fish/conf.d/git_theirs.fish
chmod a+x ~/.config/fish/conf.d/git_theirs.fish
source ~/.config/fish/conf.d/git_theirs.fish

git log -Sword

git log --oneline --find-renames --stat --follow -- src/somefile.ts

git clone --single-branch --branch <branchname> <remote-repo>

git rm --cached blah.tmp

git push <remote_name> --delete <branch_name>

git push origin HEAD:refs/heads/backdoor

5 What Git calls things

By which I mean what’s formally denoted as git references. Git references are the canonical description of the mechanics. tl;dr: the most common names are refs/heads/SOMETHING for the branch SOMETHING, and refs/tags/SOMETHING and remotes/SOMEREMOTE/SOMETHING for the (last known) state of a remote branch.

As alexwlchan explains, these references are friendly names for commits, and should be thought of as pointers to commits.

And yet there is something a little magical going on. How come, if I pull a branch, I get the latest version of that branch, not the earliest commit to use that name? Something else is happening. cf. I wish people would stop insisting that Git branches are nothing but refs.

The uses are (at least partly) convention, and we can use other references too. For example, gerrit uses refs/for/ for code review purposes.

6 Filters

Commands applied to our files on the way in and out of the repository. Keywords like smudge, clean, and .gitattr. These are a long story, but not so complicated in practice. A useful one is stripping crap from jupyter notebooks.

7 Commit hooks

For doing stuff before we put it in cold storage. e.g. asking: DID YOU REALLY WANT TO INCLUDE THAT GIANT FILE?

Here is a commit hook that does exactly that. I made a slightly modernized version:

curl -L https://gist.github.com/danmackinlay/6e4a0e5c38a43972a0de2938e6ddadba/raw/install.sh | bash

UPDATE: I decided this was a waste of time, so I removed it.

After that installation, we can retrofit the hook into an existing repository like this:

p -R ~/.git_template/hooks .git/

There are various frameworks for managing hooks, if we have lots. For example, pre-commit is a mini-system for managing Git hooks, written in Python. Husky is a node.js-based one.

Also, it is remarkably labour-intensive to install the dependencies for all these systems, so if you are using heterogeneous systems this becomes tedious. I’m not sure whether hook management systems actually save time overall for us as solo developers, since the kind of person who remembers to install a pre-commit hook is also the kind of person who is less likely to need one.

To skip the pre-commit hook,

git commit --no-verify

8 Subtrees/submodules/subprojects/subdirs/subterranean mole people

Subprojects inside other projects? External ones? The simplest way to integrate external projects seems to be as subtrees. Once this is set up we can mostly ignore them, and things work as expected. Alternatively, there are submodules, which come with various complications. More recently, there’s the Subtrac system, which I haven’t used yet.

git fetch remote branch
git subtree add --prefix=subdir remote branch --squash

git fetch remote branch
git subtree pull --prefix=subdir remote branch --squash
git subtree push --prefix=subdir remote branch --squash

pushd superproject
git subtree split -P project_subdir -b project_branch
popd
mkdir project
pushd project
git init
git pull ../superproject project_branch

pushd superproject
cd ..
git clone superproject subproject
pushd subproject
git filter-branch \
    --subdirectory-filter project_subdir \
    --prune-empty -- \
    --all

svn co https://github.com/buckyroberts/Source-Code-from-Tutorials/trunk/Python

9 Deleting all the tags

git tag -l | xargs -I %% git push -v origin :refs/tags/%%
git tag -l | xargs git tag -d && git fetch -t

10 Conventions

Many workflows are feasible with Git. Large teams often have elaborate conventions for branch names, and for who gets to merge what with whom. Here are some I have seen in the wild:

• Conventional Commits
• Trunk-based Development
• GitHub flow (which is not the same as gitflow).

Some of these systems have associated helpers; see next.

11 Helpers

Git has various layers of abstraction: a very basic infrastructure of plumbing; then notionally user-friendly, higher-level porcelain commands (which the Git authors say are user-friendly, but many of us regard as “a passable first attempt at best”); and then helper commands that smooth over common workflows and pain points.

# ~/.config/fish/functions/mkworktree.fish
function mkworktree --description "Create a git worktree and open in VS Code"
    set branch_name $argv[1]

    if test -z "$branch_name"
        echo "Error: Branch name is required"
        echo "Usage: mkworktree BRANCH_NAME"
        return 1
    end

    set repo_name (basename $PWD)
    set base_dir (dirname $PWD)
    set branches_dir "$base_dir/$repo_name"_branches

    # Create branches directory if it doesn’t exist
    if not test -d "$branches_dir"
        mkdir -p "$branches_dir"
    end

    # Create worktree
    git worktree add -b "$branch_name" "$branches_dir/$branch_name"

    if test $status -eq 0
        # Open in VS Code
        code -n "$branches_dir/$branch_name"
        echo "Worktree created and opened in VS Code: $branches_dir/$branch_name"
    else
        echo "Error creating worktree"
        return 1
    end
end

git config --global rerere.enabled true
git config --global rerere.autoupdate true

12 Importing some files from another branch

git checkout my_branch -- my_file/

13 Garbage collecting

In brief, this will purge a lot of stuff from a constipated repo in emergencies:

git reflog expire --expire=now --all && git gc --prune=now

In-depth explanation here.

14 Editing history

14.1 Cleaning out all big files

bfg does that:

git clone --mirror git://example.com/some-big-repo.git
cd some-big-repo.git
git repack
bfg --strip-blobs-bigger-than 10M .
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push -f

git filter-branch -f \
    --index-filter
    'git rm -r --cached --ignore-unmatch unwanted_files'

git archive HEAD --format=zip > archive.zip

git checkout -b temp_branch
git rebase --root -i

git reset $(git commit-tree HEAD^{tree} -m "A new start")

git checkout --orphan temp_branch
git add -A
git commit -am "Initial commit"
git branch -D master
git branch -m master
git push -f origin master

TREE=`git cat-file -p master |sed '1,/^$/s/^tree //p;d;'`
COMMIT=`echo Truncated tree | git commit-tree $TREE`
git branch truncated-master $COMMIT
git branch backup-master-just-in-case-i-regret-it-later master
git push -f origin truncated-master:master

15 Making git work with a filesystem with broken permissions

For example, we’re editing a git repo on NTFS via Linux and things get silly.

git config core.filemode false

16 Detecting whether there are changes to commit

Thomas Nyman:

if output=$(git status --porcelain) && [ -z "$output" ]; then
  # Working directory clean
else
  # Uncommitted changes
fi

17 Emergency commit

Oh crap I’m leaving the office in a hurry and I just need to get my work into Git ASAP so I can continue on another computer. I don’t care about sensible commit messages because I’m on my own private branch and no one else will see them once I squash the pull request.

I put this little script in a file called gitbang to automate this situation.

#!/usr/bin/env bash
# I’m leaving the office. Capture all changes in my private branch and push to server.
#!/usr/bin/env bash

if output=$(git status --porcelain) && [ -z "$output"]; then
  echo "nothing to commit"
else
  git add --all && git commit -m bang
fi

# Determine branch to use: either first argument or default to current branch’s upstream
branch=${1:-$(git rev-parse --abbrev-ref --symbolic-full-name "@{u}" 2>/dev/null | sed 's|^.*/||')}

# If upstream wasn’t set and no argument provided, fall back to local current branch
if [ -z "$branch" ]; then
  branch=$(git rev-parse --abbrev-ref HEAD)
fi

git pull origin "$branch" \
  && git submodule update --init --recursive \
  && git push origin HEAD:"$branch"

Pro tip: if we use VS Code there’s a feature called Cloud Changes that synchronizes our changes to the cloud, so we can pick up where we left off on another computer without arsing about with git—or so it seems.

18 Git hosting

• GitHub is the gorilla of git hosting
• GitLab has open-source and self-hosted options as well as a cloud offering
• Codeberg is a Gitea host

We don’t need to use a git hosting service at all; it’s just convenient to have a pre-arranged central meeting place. A classic way to avoid needing such a host is…

19 Git email workflows

Learn to use email with git.

20 Content-specific diffing

Tools such as git-latexdiff provide custom diffing for, in this case, LaTeX code. These need to be found on a case-by-case basis.

21 SSH credentials

Managing SSH credentials in git is not obvious. See SSH.

22 Jupyter

For sanity in git + Jupyter, see jupyter.

23 Decent GUIs

See Git GUIs.

24 Which repo are we in?

For fish and bash in the shell, see bash-git-prompt.

25 Data versioning

See data versioning.

26 Working with normies in the cloud

Working with a colleague who doesn’t like git? Try this git collab trick that lets us work in hostile file systems such as OneDrive. Cf. Trying to convince academics to use git - Juulia Suvilehto.

Create a bare repository somewhere on our local disk, outside cloud-synced folders (or use a remote Git host like GitHub; just avoid putting the repo in a cloud-synced folder):

mkdir ~/git-storage/myproject.git
cd ~/git-storage/myproject.git
git init --bare

Prepare the OneDrive workspace:

mkdir ~/OneDrive/myproject
cd ~/OneDrive/myproject

Link the workspace to a bare repo using Git’s clone-with-separation:

git clone --separate-git-dir=~/git-storage/myproject.git /dev/null .
rm .git  # Remove auto-created folder
echo "gitdir: ~/git-storage/myproject.git" > .git

Create the initial commit via a temporary clone:

cd ~/git-storage
git clone myproject.git temp-work
cd temp-work

touch README.md
git add .
git commit -m "Initial commit"
git push origin main

cd ..
rm -rf temp-work

Check out files in the OneDrive workspace:

cd ~/OneDrive/myproject
git reset --hard HEAD

Regular Git operations should work as normal:

# Make changes
echo "New content" >> file.txt
git add .
git commit -m "Update file"
git push

File structure shows a clean separation:

~/git-storage/myproject.git  # Bare repo (Git data)
~/OneDrive/myproject         # Working files (.git file only)

Key advantages: 1. No .git folder synced to the cloud 2. Full Git history stored locally in a bare repo 3. Works with all Git commands as normal 4. Easy to relocate Git data without breaking links

For Windows paths, we use doubled backslashes in the .git file: gitdir: C:\\\\path\\\\to\\\\repo.git