Posts tagged: git Archive

📝 Git Notes

2026-01-15T09:05:21Z

See old revisions of one file #

git log --oneline -- <file>
git log -n 2 --oneline -- <file>

Checkout an old revision of a file #

git checkout <commit> -- path/to/file

fuzzy pick a file and check out an old revision #

#!/usr/bin/env bash
set -euo pipefail

file="${1:-}"

if [[ -z "${file}" ]]; then
  file="$(git ls-files | fzf --prompt="select file > ")" || exit 0
fi

if [[ -z "${file}" ]]; then
  exit 0
fi

if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
  echo "Not a git repository." >&2
  exit 1
fi

if ! git ls-files --error-unmatch -- "${file}" >/dev/null 2>&1; then
  echo "File is not tracked by git: ${file}" >&2
  exit 1
fi

choice="$(
  git log --follow --pretty=format:'%h %ad %s' --date=short -- "${file}" |
    fzf --ansi --no-sort --reverse \
        --preview-window=down:70% \
        --prompt="checkout revision > " \
        --preview "git show --color=always {1}^..{1} -- '${file}' 2>/dev/null || git show --color=always {1} -- '${file}'"
)"

if [[ -z "${choice}" ]]; then
  exit 0
fi

commit="$(awk '{print $1}' <<<"${choice}")"
git checkout "${commit}" -- "${file}"

git name status

2025-12-12T07:53:57Z

--name-status is a great way to see what files have changed in a git diff alongside the status code. I recently used this in a script to create a report of new and modified files during a build.

git diff --name-status
git diff --name-status origin/main
git diff --name-status --staged
git diff --name-status 'HEAD@{3 days ago}'

tea login flag

2025-11-23T21:09:36Z

The tea command for gitea (used by forgejo) has a flag for login. With gitea you can have multiple accounts logged in. When you try to run a command such as repo create it will prompt you which login to use, but I learned that you can bake it in to all of them with --login <login-name>

❯ tea repo create --name deleteme --description 'for example'
┃ NOTE: no gitea login detected, whether falling back to login 'git.waylonwalker.com'?

tea repo create --name deleteme --description 'for example' --login git.wayl.one

💭 You already have a git server: (Maurycy's blog)

2025-10-29T13:04:20Z

Outdated client!

maurycyz.com

It’s so easy to forget low level tech sometimes. Things that are dead simple and just work without a hitch. git is one of those rock solid things thats very easy to remember all that it does, this is a classic use case.

This just works

cd /parent/directory/for/repo
git clone ssh://username@server/path/to/repo

In order to recieve you must update the remote to allow recieve.

git config receive.denyCurrentBranch updateInstead

Now you can pull update push.

It’s funny how this was the way I first learned to do Continuous Deployment to a RHEL7 machine, also how Heroku worked, but its so easy to forget this solution is there. I come across it every few years and immediately have a few use cases in mind.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

💭 Learn to use email with git!

2025-08-29T13:23:08Z

Learn to use email with git!

git-send-email.io

This site gives us a glimpse into the development workflow using git over email, without remote centralized servers. I found it interesting how patches can be sent with an optional cover letter nearly like a pr would be made.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

💭 Repository Mirrors | Forgejo – Beyond coding. We forge.

2025-08-29T00:50:50Z

Repository Mirrors | Forgejo – Beyond coding. We forge.

forgejo.org

Forgejo supports repository mirrors, I think this is how I am going to handle migrating all of my github repos into forgejo. over time I’ll probably go through and delete a bunch of unnecessary one from github, ones that might have a user or two I might keep on github. I have such small scale projects with almost no users I am not sure that It really matters for me or not.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

💭 Let's Make Sure Github Doesn't Become the only Option - Edward...

2025-08-28T23:45:53Z

Let's Make Sure Github Doesn't Become the only Option - Edward Loveall

blog.edwardloveall.com

This post is a masterclass in blogging, cross linking, backing up your ideas with posts from other great sources. I have a week of reading inside this post, and need to come back later when Im not sick.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

💭 Git Fork vs Git Clone (Animated) - YouTube

2024-07-24T17:59:00Z

Git Fork vs Git Clone" playlabel="Play: Git Fork vs Git Clone">

Damn Prime covers this so well from all angles. Can’t overstate the importance of that last step. Look at the issues, and raise an issue if there is not one before putting in a bunch of hard work. Make sure that the maintainers are open for your changes and no one else is already working on it.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

💭 Some Git poll results

2024-03-29T02:04:41Z

Some Git poll results

Julia Evans · jvns.ca

great poll of git questions

poll: did you know that in a git merge conflict, the order of the code is different when you do a merge/rebase?

merge:

<<<<<<< HEAD YOUR CODE

OTHER BRANCH’S CODE

c694cf8aabe

rebase:

«««< HEAD OTHER BRANCH’S CODE

YOUR CODE

d945752 (your commit message)

This one explains a lot. I think I knew this, I might have seen it somewhere, but I have definitely noticed it go both ways and confuse the crap out of me. Feels very similar to how --ours and --theirs flip flops.

Note

This post is a thought. It’s a short note that I make about someone else’s content online #thoughts

Two new shell aliases for git

2022-06-28T12:31:10Z

Recently I added two new bash/zsh aliases to make my git experience just a tad better.

trackme #

Most of our work repos were recently migrated to new remote urls, we scriped out the update to all of the repos, but I was left with a tracking error for all of my open branches. To easily resolve this I just made an alias so that I can just run trackme anytime I see this error.

There is no tracking information for the current branch.
    Please specify which branch you want to merge with.
    See git-pull(1) for details

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream develop origin/<branch>

getting the branch #

The following command will always return the currently checked out branch name.

git symbolic-ref --short HEAD

Injecting this into the suggested git command as a subshell gives us this alias that when ran with trackme will automatically fix tracking for my branch.

alias trackme='git branch --set-upstream-to=origin/$(git symbolic-ref --short HEAD)'

rebasemain #

I sometimes get a bit lazy at checking main for changes before submitting any prs, so again I made a quick shell alias that will rebase main into my branch before I open a pr.

alias rebasemain='git pull origin main --rebase'

The Aliases #

Here are both of the alias’s, feel free to steal and modify them into your dotfiles. If you are uniniatiated a common starting place to put these is either in your ~/.bashrch or ~/.zshrc depending on your shell of choice.

alias trackme='git branch --set-upstream-to=origin/$(git symbolic-ref --short HEAD)'
alias rebasemain='git pull origin main --rebase'

gh repo create

2022-06-10T11:53:32Z

I love getting faster in my workflow, something I have recently added in is creating GitHub repos with the cli. I often create little examples of projects, but they just end up on my machine and not anywhere that someone else can see, mostly because it takes more effort to go create a repo. TIL you can create a repo right from the command line and push to it immediately.

gh repo create waylonwalker-cli

want to see what this repo I created is about? #

Check out what I created here.

pipx run waylonwalker

git merge ours

2022-05-24T12:12:09Z

Sometimes you have a pretty old branch you are trying to merge into and you are absolutely sure what you have is what you want, and therefore you don’t want to deal with any sort of merge conflicts, you would rather just tell git to use my version and move on.

update main #

The first step is to make sure your local copy of the branch you are moving into is up to date.

git checkout main
git pull

update your feature branch #

It’s also worth updating your feature branch before doing the merge. Maybe you have teammates that have updated the repo, or you popped in a quick change from the web ui. It’s simple and worth checking.

git checkout my-feature
git pull

start the merge #

Merge the changes from main into my-feature branch.

git merge main

Now is where the merge conflict may have started. If you are completely sure that your copy is correct you can --ours, if you are completely sure that main is correct, you can --theirs.

git checkout --ours .
git merge --continue

This will pop open your configured git.core.editor or $EDTIOR. If you have not configured your editor, it will default to vim. Close vim with <escape>:x, accepting the merge message.

Now push your changes that do not clash with main and finish your pr.

git push

List all git commits with GitPython

2022-05-09T21:24:12Z

I am getting ready to do some timeseries analysis on a git repo with python, my first step is to figure out a way to list all of the git commits so that I can analyze each one however I want. The GitPython library made this almost trivial once I realized how.

from git import Repo

repo = Repo('.')
commits = repo.iter_commits()

This returns a generator, if you are iterating over them this is likely what you want.

commits
# <generator object Commit._iter_from_process_or_stream at 0x7f3307584510>

The generator will return git.Commit objects with lots of information about each commit such as hexsha, author, commited_datetime, gpgsig, and message.

next(commits)
# <git.Commit "d125317892d0fab10a36638a2d23356ba25c5621">

GPG signing commits over ssh

2022-05-08T15:09:59Z

I was editing some blog posts over ssh, when I ran into this error. gpg was failing to sign my commits. I realized that this was because I could not answer to the desktop keyring over ssh, but had no idea how to fix it.

Error #

This is the error message I was seeing.

gpg failed to sign the data ssh

The fix #

The fix ended up being pretty simple, but quite a ways down this stack overflow post. This environment variable tells gpg that we are not logged into a desktop and it does not try to use the desktop keyring, and asks to unlog the gpgkey right in the terminal.

export GPG_TTY=$(tty)

This is what it looks like when it asks for the passphrase.

EDIT-another way #

So this did not fix the issue on Arch BTW, and I have seen it not work for wsl users either. This did work for me and reported to have worked by a wsl user on a github issue.

echo '' | gpg --clearsign

This will unlock the gpg key then let you commit.

Review Pull Requests with git worktrees

2022-05-04T14:31:05Z

Sometimes you get a PR on a project, but cannot review it without wrecking your current working setup. This might be because it needs to be compiled, or a new set of requirements. Git worktrees is a great way to chekout the remote branch in a completely separate directory to avoid changing any files in your current project.

# pattern
# git worktree add -b <branch-name> <PATH> <remote>/<branch-name>
git worktree add -b fix-aws-service-cnsn /tmp/project origin/fix-aws-service-cnsn

This will create a new directory /tmp/project that you can review the branch fix-aws-service-cnsn from the remote origin. If you have setup different remotes locally you can check for the name of it with git remote -v

Using Git from Python

2022-04-30T20:23:23Z

GitPython is a python api for your git repos, it can be quite handy when you need to work with git from python.

Use Case #

I recently made myself a handy tool for making screenshots in python and it need to do a git commit and push from within the script. For this I reached for GitPython.

How I Quickly Capture Screenshots directly into My Blog

Installation #

GitPython is a python library hosted on pypi that we will want to install into our virtual environments using pip.

pip install GitPython

Create a Repo Object #

Import Repo from the git library and create an instance of the Repo object by giving it a path to the directory containing your .git directory.

from git import Repo
repo = Repo('~/git/waylonwalker.com/')

Two interfaces #

from the docs

It provides abstractions of git objects for easy access of repository data, and additionally allows you to access the git repository more directly using either a pure python implementation, or the faster, but more resource intensive git command implementation.

I only needed to use the more intensive but familar to me git command implementation to get me project off the ground. There is a good tutorial to get you started with their pure python implementation in their docs.

Status #

Requesting the git status can be done as follows.

note I have prefixed my commands with »> to distinguish between the command I entered and the output.

>>> print(repo.git.status())

On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        blog/

You can even pass in flags that you would pass into the cli.

>>> print(repo.git.status("-s"))
?? blog/

log #

Example of using the log.

print(repo.git.log('--oneline', '--graph'))

* 0d28bd8 fix broken image link
* 3573928 wip screenshot-to-blog
* fed9abc wip screenshot-to-blog
* d383780 update for wsl2
* ad72b14 wip screenshot-to-blog
* 144c2f3 gratitude-180

Find Deleted Files #

We can even do things like find all files that have been deleted and the hash they were deleted.

print(repo.git.log('--diff-filter', 'D', '--name-only', '--pretty=format:"%h"'))

git find deleted files

full post on finding deleted files

My Experience #

This library seemed pretty straightforward and predicatable once I realized there were two main implementations and that I would already be familar with the more intensive git command implementation.

Set Your Git Pager Config

2022-03-16T14:03:18Z

Setting up your git pager to your liking can help you navigate diffs and logs much more efficiently. You can set it to whatever pager you like so that your keys feel nice and smooth and your fingers know exactly what to do. You might even gain a few extra features.

You can set the pager right from your command line with the following command.

git config --global core.pager 'more'

You can also set your pager by editing your global .gitconfig file which by default is set to ~/.gitconfig.

[core]
    pager = more

Color #

In my experience you need to turn colors off with nvim. bat handles them and looks good either way, but nvim will be plain white and display the color codes as plain text if color is on.

git config --global color.pager no

Pagers I have tried #

Here are some various configs that I tried. For some reason line numbers in bat really bothered me, but when in nvim they felt ok. I am going to try running both of them for a few days and see which I like better. I think having some of my nvim config could be really handy for things like yanking a commit hash to the system clipboard without touching the mouse.

# bat
git config --global core.pager 'bat'

# nvim in read only mode
git config --global core.pager 'nvim -R'

# turn colors off
git config --global color.pager no

# bat with no line numbers
git config --global core.pager 'bat --style=plain'

# nvim with no line numbers and a specific rc file
git config --global core.pager "nvim -R +'set nonumber norelativenumber' -u ~/.config/nvim/init-git.vim"

reset back to the default #

If you are afraid to try one of these settings, don’t be you can always change it back. If you tried one and dont like it just --unset the config that you just tried.

git config --global --unset core.pager
git config --global --unset color.pager

The other option you have is to open your .gitconfig file and delete the lines of config that set your pager.

Configure Git to Autocorrect Your Fat Fingers

2022-03-15T00:43:25Z

If you have ever mistyped a git command very close to an existing one you have likely seen this message.

❯ git chekout dev
git: 'chekout' is not a git command. See 'git --help'.

The most similar command is
        checkout

Automatically run the right one #

What you might not have known is that you can configure git to just run this command for you.

# Gives you 0.1 seconds to respond
git config --global help.autocorrect 1

# Gives you 1 seconds to respond
git config --global help.autocorrect 10

# Gives you 5 seconds to respond
git config --global help.autocorrect 50

Fat Fingers Gone #

Now when you typo a git command it will autmatically run after the configured number of tenths of a second.

❯ git chkout get-error
WARNING: You called a Git command named 'chkout', which does not exist.
Continuing in 1.0 seconds, assuming that you meant 'checkout'.
M       pages/blog/how-i-deploy-2021.md
M       pages/hot_tips/001.md
M       pages/templates/gratitude_card.html
M       plugins/index.py
M       plugins/publish_amp.py
M       plugins/render_template_variables.py
M       plugins/youtube.py
M       requirements.txt
M       static/index.html
Switched to branch 'get-error'

My config #

I’m rocking 10 for now just to see how I feel about it, but honestly I cannot think of a time that I have seen the original warning that was not what I wanted. This at least gives me some time to respond if I am unsure.

git config --global help.autocorrect 10

Git Worktrees are not so Scary

2022-03-10T19:19:34Z

So worktrees, I always thought they were a big scary things. Turns out they are much simpler than I thought.

Myth #1 #

no special setup

I thought you had to be all in or worktrees or normal git, but not both. When I see folks go all in on worktrees they start with a bare repo, while its true this is the way you go all in, its not true that this is required.

Lets make a worktree #

Making a worktree is as easy as making a branch. It’s actually just a branch that lives in another place in your filesystem.

# checkout a new worktree called compare based on main in /tmp/project
git worktree add -b compare /tmp/project main

# checkout a new worktree called compare based on HEAD in /tmp/project
git worktree add -b compare /tmp/project

# checkout a worktree from an existing feature branch in /tmp/project
git worktree add /tmp/project my-existing-feature-branch

The worktree that you create is considered a linked worktree, while the original worktree is called the main worktree

Note that I put this in my tmp directory because I don’t expect it to live very long, my recent use case was to compare two files after a big formatting change. You put these where you want, but dont come at me when your /tmp gets wiped and you loose work.

Myth #2 #

they are hidden mysterious creatures

Just like branches git has some nice commands to help us understand what worktrees we have on our system. Firstly we have something very specific to worktrees to list them out.

git worktree list

gives the output

/home/u_walkews/git/git-work-play  b202442 [main]
/tmp/another                       d9b2cf1 [another]

Even the branch command gives a bit different output for a worktree.

git branch

gives this output, notice the + denotes an actively linked worktree, and the * gives the active branch. If you cd over to the worktree directory, these will switch roles.

+ another
  just-a-branch
* main

You can only checkout a branch in one place #

If you try to checkout a branch that is checked out in a linked worktree, you will be presented with an error, and it will not let you check out a second copy of that branch.

❯ git checkout another
fatal: 'another' is already checked out at '/tmp/another'

Myth #3 #

once you go worktree, you worktree

Once you have worktrees on your system, you have a few ways to get rid of them. Using git’s way feels much superior, but if your a doof like me and didn’t read the manual before you rm /tmp/another -rf you will notice that the worktree is still active. If you run git worktree prune it will clean that right up.

git worktree remove another

rm /tmp/another
git worktree prune

It won’t let you remove if you have changes #

This makes me think that remove is a much safer option. If you have uncommitted changes, git worktree remove will throw an error, and make you commit or use --force to remove the worktree.

❯ git worktree remove another
fatal: 'another' contains modified or untracked files, use --force to delete it

RTFM #

read the friendly manual

There is a ton more information in the man page for worktrees, these are just the parts that seemed really useful to me out of the gate.

man git worktree

Configure Git to Always Push to the Current Branch

2022-03-09T13:45:18Z

Has no upstream branch errors in git can be such a damn productivity killer. You gotta stop your flow and swap over the branch, there is a config so that you don’t have to do this.

fatal has no upstream branch #

If you have not yet configured git to always push to the current branch, you will get a has no upstream branch error if you don’t explicitly set it.

Let’s show an example

git checkout -b feat/ingest-inventory-data
git add conf/base/catalog.yml
git commit -m "feat: ingest inventory data from abc-db"
git push

You will be presented with the following error.

fatal: The current branch feat/ingest-inventory-data has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feat/ingest-inventory-data

Option 1: follow the instructions #

To resolve this fatal error your first option is simply to follow the instructions given. Just copy and paste it in.

git push --set-upstream origin feat/ingest-inventory-data

Option 2: push to the current branch without setting upstream #

Honestly, I am pretty aware of the branch I am on, and Very few times have I ever accidentally pushed to the wrong branch. The one that you might have a bigger chance with a more detrimental effect is main, which I will argue you should have blocked to require a passing ci, and potential reviewers to merge in. Therefore you can’t even push to main anyway.

To just push to the branch you are currently on each and every time and never see this error again, you can run this to configure git to always push to your current branch.

git config --global push.default current

Recover a lost git branch with checkout

2022-03-01T14:34:01Z

Once you give a branch the big D (git branch -D mybranch) its gone, its lost from your history. It’s completely removed from your log. There will be no reference to these commits, or will there?

TLDR #

Checkout is your savior, all you need is the commit hash.

Immediate Regret #

your terminal is still open

We have all done this, you give branch the big D only to realize it was the wrong one. Don’t worry, not all is lost, this is the easiest to recover from. When you run the delete command you will see something like this.

❯ git branch -D new
Deleted branch new (was bc02a64).

Notice the hash is right there is the hash of your commit. You can use that to get your content back.

git checkout -b bc02a64
git branch new

# or in one swoop checkout your new branch at the `start-point` you want
git checkout -b new bc02a64

Delayed reaction #

you have closed your terminal

If you have closed your terminal, or have deleted with a gui or something that does not tell you the hash as you run it, don’t fret, all your work is still there (as long as you have commited). You just have to dig it out. The reflog contains a list of all git operations that have occurred on your git repo, and can be incredibly helpful with this.

Kinda Recent #

If your botched delete operation was recent just diving right into the reflog will show it.

❯ git reflog
03a3338 (main) HEAD@{0}: checkout: moving from new to main
bc02a64 (HEAD -> another, new) HEAD@{4}: commit: newfile
03a3338 (main) HEAD@{2}: checkout: moving from main to new

In this example, I checked out a branch called new, commited a new file, then switched back to main and deleted new.

Now That I have the commit hash I can use the same solution to get my branch back.

git checkout -b bc02a64
git branch new

# or in one swoop checkout your new branch at the `start-point` you want
git checkout -b new bc02a64

A lot has happened since then #

If a lot has happened since then, you are going to need to pull out some more tool to sift through that reflog, especially if its a big one. The first suggestion that I have is to pipe into grep and look for commit messages, or the name of the branch.

❯ git reflog | grep "moving from"
03a3338 HEAD@{1}: checkout: moving from main to branch/oops
03a3338 HEAD@{2}: checkout: moving from oops to main
03a3338 HEAD@{4}: checkout: moving from main to oops
03a3338 HEAD@{5}: checkout: moving from another to main
bc02a64 HEAD@{6}: checkout: moving from main to another
03a3338 HEAD@{7}: checkout: moving from another to main
bc02a64 HEAD@{8}: checkout: moving from new to another
bc02a64 HEAD@{9}: checkout: moving from bc02a64bbe5683d905e333e8dfcbbb91a5e77549 to new
bc02a64 HEAD@{10}: checkout: moving from main to bc02a64bbe56
03a3338 HEAD@{11}: checkout: moving from new to main
03a3338 HEAD@{13}: checkout: moving from main to new
03a3338 HEAD@{14}: checkout: moving from other to main
03a3338 HEAD@{18}: checkout: moving from main to other

git has a built in --grep flag, but I don’t think there is a way to filter by branch name, regardless it still is helpful.

❯ git reflog --grep new
bc02a64 (HEAD -> another, new) HEAD@{4}: commit: newfile

Maybe if you can remember a filename you can pass in -- <filename>.

git reflog -- readme.md

RTFM #

There are many other ways to slice up a git log, and reflog alike. check out man git log for some more flags.

git find deleted files

2022-02-28T16:45:19Z

It’s nearly impossible to completely loose a file if it is commited to git. It’s likely harder to fully remove the file than it is to recover it, but how do we go about recovering those precious files that we have lost.

Listing all the deleted files in all of git history can be done by combining git log with --diff-filter. The log gives you lots of options to show different bits of information about the commit that happened at that point. It’s even possible to get a completely clean list of files that are in your git history but have been deleted.

git log –diff-filter #

These various commands will show all files that were ever deleted on your current branch.

# This one includes the date, commit hash, and Author
git log --diff-filter D

# this one could be a git alias, but includes empty lines
git log --diff-filter D --pretty="format:" --name-only

# this one has the empty lines cleaned up
git log --diff-filter D --pretty="format:" --name-only | sed '/^$/d'

git diff-filter

git reflog –diff-filter #

The reflog can be super powerful in finding lost files here, as it only cares about git operations, not just the current branch. It will search accross all branches for deleted files and report them.

# This one includes the commit hash, branch, tag, and commit message
git reflog --diff-filter D

# You might want to at least add the filename
git reflog --diff-filter D --name-only

# this one could be a git alias, but includes empty lines
git reflog --diff-filter D --pretty="format:" --name-only

# this one has the empty lines cleaned up
git reflog --diff-filter D --pretty="format:" --name-only | sed '/^$/d'

get the last commit from a file #

git log -n 1 --pretty=format:%H -- file

If you want dont like how the output looks or you want your default pager to be different you can configure the default pager see Set Your Git Pager Config.

git diff-filter

2022-02-27T16:34:31Z

Git commands such as diff, log, whatchanged all take a flag called --diff-filter. This can filter for only certain types of diffs, such as added (A), modified (M), or deleted (D).

Man page #

You can find the full description by searching for --diff-filter in the man git diff page.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
    Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, ...)
    changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B). Any combination of the filter characters (including none) can be used.
    When * (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no
    file that matches other criteria, nothing is selected.

    Also, these upper-case letters can be downcased to exclude. E.g.  --diff-filter=ad excludes added and deleted paths.

    Note that not all diffs can feature all types. For instance, diffs from the index to the working tree can never have Added entries (because the set of paths
    included in the diff is limited by what is in the index). Similarly, copied and renamed entries cannot appear if detection for those types is disabled.

Try it out #

Open up a git repo and play around with this, here are some example that I played with that seemed useful to me.

# find when any files were deleted
git log --diff-filter D

# find when all files were added
git log --diff-filter A

# only one specific file
git log --diff-filter A -- readme.md

# partial match to a single file
git log --diff-filter A -- read*

# Find when all python files were added
git log --diff-filter A -- *.py

Git rebase to the beginning of time

2022-02-23T15:57:37Z

Git has a built in way to rebase all the way back to the beginning of time. There is no need to scroll through the log to find the first hash, or find the total number of commits. Just use --root.

git rebase --root

Revive files from the dead with git

2022-02-21T15:44:02Z

Git reflog can perform some serious magic in reviving your hard work from the dead if you happen to loose it.

caveat #

You must git commit! If you never commit the file, git cannot help you. You might look into your trashcan, filesystem versions, onedrive, box, dropbox. If you have none of this, then you are probably hosed.

practice #

I really like to practice these techniques before I need to use them so that I understand how they work in a low stakes fashion. This helps me understand what I can and cannot do, and how to do it in a place that does not matter in any way at all.

This is what I did to revive a dropped docker-compose.yml file. The idea is that if I can find the commit hash, I can cherry-pick it.

git init
touch readme.md
git add readme.md
git commit -m "add readme"
touch docker-compose.yml
git add docker-compose.yml
git commit -m "add docker-compose"
git reset 3cfc --hard
git reflog
# copy the hash of the commit with my docker-compose commit
git cherry-pick fd74df3

reflog #

Here was the final reflog that shows all of my git actions. note I did reset twice.

❯ git reflog --name-only
0404b6a (HEAD -> main) HEAD@{0}: cherry-pick: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{1}: reset: moving to 3cfc
readme.md
9175695 HEAD@{2}: cherry-pick: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{3}: reset: moving to 3cfc
readme.md
fd74df3 HEAD@{4}: commit: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{5}: reset: moving to HEAD
readme.md
3cfcab9 HEAD@{6}: commit (initial): add readme
readme.md

Git reflog is an alias for git log -g

2022-02-19T15:02:52Z

Right inside the git docs, is states that the git reflog command runs git reflog show by default which is an alias for git log -g --abbrev-commit --pretty=oneline

This epiphany deepens my understanding of git, and lets me understand that most git log flags might also work with git log -g.

full or short format #

Here are some git commands for you to try out on your own that are all pretty similar, but vary in how much information they show.

# These show only first line of the commit message subject, the hash, and index
git reflog
git log -g --abbrev-commit --pretty=oneline

# similar to git log, this is a fully featured log with author, date, and full
# commit message
git log -g

add files #

If I am looking for a missing file, I might want to leverage --name-only or --stat, to see where I might have hard reset that file, or deleted it.

git reflog --stat
git log -g --stat --abbrev-commit --pretty=oneline

git reflog --name-only
git log -g --name-only --abbrev-commit --pretty=oneline

example #

Here is an example where I lost my docker-compose.yml file in a git reset, and got it back by finding the commit hash with git reflog and cherry picked it back.

❯ git reflog --name-only
0404b6a (HEAD -> main) HEAD@{0}: cherry-pick: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{1}: reset: moving to 3cfc
readme.md
9175695 HEAD@{2}: cherry-pick: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{3}: reset: moving to 3cfc
readme.md
fd74df3 HEAD@{4}: commit: add docker-compose
docker-compose.yml
3cfcab9 HEAD@{5}: reset: moving to HEAD
readme.md
3cfcab9 HEAD@{6}: commit (initial): add readme
readme.md

This just proves that its harder to remove something from git, than it is to get it back. It can feel impossible to get something back, but once its in, it feels even more impossible to get it out.

A Good Use for global .gitignore

2022-01-30T02:11:51Z

I’ve never found a great use for a global .gitignore file. Mostly I fear that by adding a lot of the common things like .pyc files it will be missing from the project and inevitably be committed to the project by someone else.

Personal Tools #

Within the past year I have added some tools to my personal setup that are not required to run the project, but works really well with my setup. They are direnv and pyflyby. Since these both support project level configuration, are less common, and not in most .gitignore templates they make for great candidates to add to a global .gitignore file.

create the config #

Like any .gitignore it supports gits wildignore syntax. I made a ~/dotfiles/git/.global_gitignore file, and added the following to it.

.envrc
.pyflyby
.copier-defaults
.venv*/
.python-version
markout
.markata.cache

Once I had this file, I stowed it into ~/.global_gitignore.

cd ~/dotfiles/
stow git

Always stow your dotfiles, don’t set yourself up for wondering why your next machine is not working right.

stow note #

Note, the reason that it is a ~/.global_gitignore and not a ~/.gitignore is that I was unable to stow a .gitignore file. They must be ignored by default, and I was unable to figure out how to turn it back on.

set the config #

Next run this command to add the ~/.global_gitignore to your gitignore as a global excludesfile.

git config --global core.excludesfile ~/.global_gitignore

commit it #

Once you have done this you should have both your ~/dotfiles/git/.gitconfig and ~/dotfiles/.global_gitignore ready to commit.

cd ~/dotfiles

git add git/.global_gitignore
git add git/.gitconfig

git commit -m "add global_gitignore"

You didn’t stow your .gitconfig #

the shame!

No worries, lets get it into your dotfiles repo and stow it.

cd ~/dotfiles

# if you dont have a git directory make it.
mkdir git
mv ~/.gitconfig ~/devtainer/git
# now use stow to symlink it back to where it was
# so git works as expected.
stow git

You dont have a dotfiles directory #

double shame 😲

If you dont already have a dotfiles directry you should. It is important for it to be in your home directory for stow to work properly, if you really don’t want it there, look up how to configure stow to account for this.

# make a dotfiles directory and go there
mkdir ~/dotfiles
cd ~/dotfiles

# make it a git repo
git init

# if you dont have a git directory make it.

mkdir git
mv ~/.gitconfig ~/devtainer/git
# now use stow to symlink it back to where it was
# so git works as expected.
stow git

fugitive verbose commit

2021-12-22T19:34:18Z

Fugitive comes with a pretty sick way to commit files and see the diff at the same time with verbose commit. Opening the fugitive menu with :G brings up your git status, you can stage files with s, unstage them with u, toggle them with -, and toggle their diff with >. Once you have staged your files for commit, you can commit with cc, but today I found that you can commit verbose with cvc. This brings up not only a commit widow with your git status shown, but the diff that you are about to commit.

example of a verbose commit in fugitive

Code Review from the comfort of vim | Diffurcate

2021-12-04T11:34:47Z

I often review Pull requests from the browser as it just makes it so easy to see the diffs and navigate through them, but there comes a time when the diffs get really big and hard to follow. That’s when its time to bring in the comforts of vim.

https://youtu.be/5NKaZFavM0E

Plugins needed #

This all stems from the great plugin by AndrewRadev. It breaks a down into a project. So rather than poping into a pager from git diff, you can pipe to diffurcate and it will setup a project in a tmp directory for you and you can browse this project just like any other except it’s just a diff.

Plug 'AndrewRadev/diffurcate.vim'

My aliases #

First to quickly checkout PR’s from azure devops I have setup an alias to fuzzy select a pr and let the az command do the checkout.

alias azcheckout='az repos pr checkout --id $(az repos pr list --output table | tail -n -2 | fzf | cut -d " " -f1)'

Next I have a few aliases setup for checking diffs. The first one checks what is staged vs the current branch, the others check the current branch vs main or master.

alias diffstaged="git diff --staged | nvim - +Diffurcate '+Telescope find_files'"
alias diffmain="git diff main.. | nvim - +Diffurcate '+Telescope find_files'"
alias diffmaster="git diff master.. | nvim - +Diffurcate '+Telescope find_files'"

diffcommit() {
    git diff $1 | nvim - +Diffurcate '+Telescope find_files'
}

Links #

diffurcte.vim

Git in Depth Notes

2021-07-31T08:44:44Z

These are my notes from taking @nnja’s FEM course git-in-depth.

requirements #

git --version > than 2.0

git">creating a git #

echo "hello" | git hash-object --stdin

How I configure git

2021-06-25T20:50:45Z

Git can be a bit tricky to get configured correctly. I often stumble into config issues weeks after setting up a new machine that I did not even notice. These are my notes to remind me how I configure git.

Identity #

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

rebase #

editor #

git config --global core.editor nvim

default branch #

git config --global init.defaultBranch main

push to current bransh wihtout setting upstream #

git config --global push.default current

Autostash #

git config pull.rebase true
git config rebase.autoStash true

How to use git cherry pick

2021-05-13T08:51:45Z

~/git via 🐍 v3.8.5
❯ mkdir git-cherry-pick-learn

~/git via 🐍 v3.8.5
❯ cd git-cherry-pick-learn

~/git/git-cherry-pick-learn
❯ git init
Initialized empty Git repository in /home/walkews/git/git-cherry-pick-learn/.git/

git-cherry-pick-learn on  main
❯ touch readme.md

git-cherry-pick-learn on  main [?]
❯ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        readme.md

nothing added to commit but untracked files present (use "git add" to track)

git-cherry-pick-learn on  main [?]
❯ git add .

git-cherry-pick-learn on  main [+]
❯ git commit -m "init readme"
[main (root-commit) ebd1ff2] init readme
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 readme.md

git-cherry-pick-learn on  main
❯ echo "Learn Cherry Pick"
Learn Cherry Pick

git-cherry-pick-learn on  main
❯ git add .

git-cherry-pick-learn on  main
❯ git commit -m "add title

git-cherry-pick-learn on  main
❯ echo "# Learn Cherry Pick" > readme.md

git-cherry-pick-learn on  main [!]
❯ git add .

git-cherry-pick-learn on  main [+]
❯ git diff

git-cherry-pick-learn on  main [+]
❯ git diff --staged
diff --git a/readme.md b/readme.md
index e69de29..3490cef 100644
--- a/readme.md
+++ b/readme.md
@@ -0,0 +1 @@
+# Learn Cherry Pick

git-cherry-pick-learn on  main [+]
❯ git commit -m "add title"
[main 148264d] add title
 1 file changed, 1 insertion(+)

git-cherry-pick-learn on  main
❯ git checkout -b trash-branch
Switched to a new branch 'trash-branch'

git-cherry-pick-learn on  trash-branch
❯ echo >> readme.md

git-cherry-pick-learn on  trash-branch [!]
❯ echo >> readme.md

git-cherry-pick-learn on  trash-branch [!]
❯ echo >> "Cherry Pick is amazing"

git-cherry-pick-learn on  trash-branch [!?]
❯ cat readme.md
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: readme.md
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ # Learn Cherry Pick
   2 + │
   3 + │
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

git-cherry-pick-learn on  trash-branch [!?]
❯ echo  "Cherry Pick is amazing" >>

git-cherry-pick-learn on  trash-branch [!?]
❯ git commit -m "add whitespace"
On branch trash-branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        Cherry Pick is amazing

no changes added to commit (use "git add" and/or "git commit -a")

git-cherry-pick-learn on  trash-branch [!?]
❯ git add .

git-cherry-pick-learn on  trash-branch [+]
❯ git commit -m "add whitespace"
[trash-branch 94f734b] add whitespace
 2 files changed, 3 insertions(+)
 create mode 100644 Cherry Pick is amazing

git-cherry-pick-learn on  trash-branch
❯ echo "TRASH" >> readme.md

git-cherry-pick-learn on  trash-branch [!]
❯ git add .

git-cherry-pick-learn on  trash-branch [+]
❯ git commit -m "add trash"
[trash-branch ec43879] add trash
 1 file changed, 1 insertion(+)

git-cherry-pick-learn on  trash-branch
❯ echo "Cherry Pick is Amazing" >> readme.md

git-cherry-pick-learn on  trash-branch [!]
❯ git commit -m "add cherry pick is amazing"
On branch trash-branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.md

no changes added to commit (use "git add" and/or "git commit -a")

git-cherry-pick-learn on  trash-branch [!]
❯ git add .

git-cherry-pick-learn on  trash-branch [+]
❯ git commit -m "add cherry pick is amazing"
[trash-branch 6691a34] add cherry pick is amazing
 1 file changed, 1 insertion(+)

git-cherry-pick-learn on  trash-branch
❯ cat readme.md
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: readme.md
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ # Learn Cherry Pick
   2   │
   3   │
   4   │ TRASH
   5   │ Cherry Pick is Amazing
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

git-cherry-pick-learn on  trash-branch
❯ git log
commit 6691a343e0ba35d0700c49ec09a99fa8f1f385b9 (HEAD -> trash-branch)
Author: Waylon Walker <walker_waylon_s@cat.com>
Date:   Thu May 13 08:54:58 2021 -0500

    add cherry pick is amazing

commit ec438790af36c23aef8eee2122f0dda95313496b
Author: Waylon Walker <walker_waylon_s@cat.com>
Date:   Thu May 13 08:54:07 2021 -0500

    add trash

commit 94f734b1adcee0f503c818c0f6bc9da97a0066e2
Author: Waylon Walker <walker_waylon_s@cat.com>
Date:   Thu May 13 08:50:35 2021 -0500

    add whitespace

commit 148264da5641033caa537727c6d5199068d58a4d (main)
Author: Waylon Walker <walker_waylon_s@cat.com>
Date:   Thu May 13 08:48:58 2021 -0500

    add title

commit ebd1ff22493d860e001f2b96ec948684d496355b
Author: Waylon Walker <walker_waylon_s@cat.com>
Date:   Thu May 13 08:47:10 2021 -0500

    init readme

git-cherry-pick-learn on  trash-branch
❯ git checkout main
Switched to branch 'main'

git-cherry-pick-learn on  main
❯ cat readme.md
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: readme.md
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ # Learn Cherry Pick
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Trim unused git branches

2021-05-07T09:47:24Z

Trim branches no longer on origin #

git remote prune origin --dry-run
git remote prune origin

Find branches already merged #

git checkout main
# list remote branches that have already been merged into main
git branch -r --merged
# list local branches that have already been merged into main
git branch --merged

Gitui is a blazing fast terminal git interface

2021-01-17T00:00:00Z

GitUI #

Gitui is a terminal-based git user interface (TUI) that will change the way that you work with git.

Works alongside the cli #

I have been a long-time user of the git cli, and it’s been hard to beat, mostly because there is nothing that keeps my fingers on the keyboard quite like it, except gitui which comes with some great ways to very quickly walk through a git project.

installation #

Go to their [releases]https://github.com/extrawurst/gitui/releases) page, download the latest build, and pop it on your PATH. I have the following stuffed away in some install scripts to get the latest version.

install latest release

GITUI_VERSION=$(curl --silent https://github.com/extrawurst/gitui/releases/latest | tr -d '"' | sed 's/^.*tag\///g' | sed 's/>.*$//g' | sed 's/^v//')
wget https://github.com/extrawurst/gitui/releases/download/v${GITUI_VERSION}/gitui-linux-musl.tar.gz -O- -q | sudo tar -zxf - -C /usr/bin/

run `gitui` #

It opens blazing fast.

gitui

Quick Commits #

Sometimes I edit a number of files and want to commit them one at a time, this is painful in the git cli and my main use case for gitui. gitui shows unstaged changes at the top, staged changes on the bottom, and a diff on the right.

Navigate with hjkl #

By default, gitui uses arrow keys, but simply copying vim_style_key_config.ron to your config directory will get you vim-like keybindings.

workflow #

pop open gitui,
use j/k to get to the file I want to commit,
glance at the diff to the right
press enter to stage the file
sc to switch focus to the saged files and commit
write my commit message hit enter and
q to quit

Keybindings #

w/s:   to toggle focus between working and staged changes
j/k:   to scroll each section
h/l:   switch between left and right side
enter: toggle file from working or staging
c:     start a commit message
p:     push
<c-c>: quit

Other Panes #

I am in the Status [1] pane 90% of the time, but it also has three other panes for Log [2], Stashing [3], and Stashes [4]. I do not really use the stashes panes, but the Log [2] pane is quite useful to quickly go through the last set of commits and see the diff for each of them.

What UI do you use for git #

Let me know what ui you use for git, do you stick to the cli, use a gui, or use a similar TUI interface?

Gitui is a blazing fast terminal git interface

2021-01-17T00:00:00Z

Gitui is a terminal-based git user interface (TUI) that will change the way that you work with git. I have been a long-time user of the git cli, and it’s been hard to beat, mostly because there is nothing that keeps my fingers on the keyboard quite like it, except gitui which comes with some great ways to very quickly walk through a git project.

installation #

install latest release

GITUI_VERSION=$(curl --silent https://github.com/extrawurst/gitui/releases/latest | tr -d '"' | sed 's/^.*tag\///g' | sed 's/>.*$//g' | sed 's/^v//')
wget https://github.com/extrawurst/gitui/releases/download/v${GITUI_VERSION}/gitui-linux-musl.tar.gz -O- -q | sudo tar -zxf - -C /usr/bin/

run `gitui` #

It opens blazing fast.

gitui

Quick Commits #

Navigate with hjkl #

By default, gitui uses arrow keys, but simply copying vim_style_key_config.ron to your config directory will get you vim-like keybindings.

workflow #

Generally, I pop open gitui, use j/k to get to the file I want to commit, glance at the diff to the right, press enter to stage the file, sc to switch focus to the saged files and commit, write my commit message hit enter and done.

w/s: to toggle focus between working and staged changes
j/k: to scroll each section
h/l: switch between left and right side
enter: toggle file from working or staging
c: start a commit message
p: push
: quit

Other Panes #

What UI do you use for git #

Let me know what ui you use for git, do you stick to the cli, use a gui, or use a similar TUI interface?

Fix git commit author

2020-10-17T05:00:00Z

I was 20 commits into a hackoberfest PR when I suddenly realized they they all had my work email on them instead of my personal email 😱. This is the story of how I corrected my email address on 19 individual commits after already submitting for a PR.

Change the email for this repo #

stop the bleeding

Before anything else set the email correctly!

cd kedro
git config user.name "Waylon Walker"
git config user.email quadmx08@gmail.com

Prepare for rebasing #

First thing is to find how many commits back this mistake goes. I opened up the git log, and saw mine went back 19 commits. I rolled back 20 just to be sure.

$ git log
...
commit a355926b9d7ec4c05659adaa254beefbdb036332
Author: WaylonWalker <email@work.com>
Date:   Sat Oct 17 10:28:59 2020 -0500

    give name of function inside incorrect parameters error

commit 1756f5d121bd06c459560b2e982e0d7b6879e9ca
Author: Kiyohito Kunii (Kiyo) <8097799+921kiyo@users.noreply.github.com>
Date:   Fri Oct 2 15:33:09 2020 +0100

    Fix docs reference for registering `pipelines`

start the rebase #

Now I start the rebase 20 commits back from HEAD. THis will pop you into a text file with a list of commits, for this change simply replace all pick with edit.

git rebase -i HEAD~20

Note for the first commit #

If you want to rebase back to the start of the repo use the --root flag.

git rebase -i --root

Run git log to see where we ended up.

$ git log
commit 1756f5d121bd06c459560b2e982e0d7b6879e9ca
Author: Kiyohito Kunii (Kiyo) <8097799+921kiyo@users.noreply.github.com>
Date:   Fri Oct 2 15:33:09 2020 +0100

    Fix docs reference for registering `pipelines`

As expected we ended up on Kiyo’s commit. So we can simply move forward without any edits.

$ git rebase --continue
Stopped at e162ca7...  correct function name in tests
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

🛠 Fix First wrong Commit #

Checking the log again I an now on my first commit with a mistake.

$ git log
commit 95c209a740d6d0340e19a8fc36298cbf874f8bf7 (HEAD)
Author: WaylonWalker <email@work.com>
Date:   Sat Oct 3 11:59:44 2020 -0500

    correct function name in tests

commit cde2e8baa3c1c4a9f1da4135258381466b1da40a
Author: Waylon Walker <quadmx08@gmail.com>
Date:   Sat Oct 17 10:30:07 2020 -0500

    update tests

commit a355926b9d7ec4c05659adaa254beefbdb036332
Author: Waylon Walker <quadmx08@gmail.com>
Date:   Sat Oct 17 10:28:59 2020 -0500

    give name of function inside incorrect parameters error

commit 1756f5d121bd06c459560b2e982e0d7b6879e9ca
Author: Kiyohito Kunii (Kiyo) <8097799+921kiyo@users.noreply.github.com>
Date:   Fri Oct 2 15:33:09 2020 +0100

    Fix docs reference for registering `pipelines`

Running the following command will reset the author on the current commit.

git commit --amend --reset-author

Double check with a quick git log that the author was fixed.

commit ccaaa56059ee4554731fa83297ca9e8e387a7592 (HEAD)
Author: Waylon Walker <quadmx08@gmail.com>
Date:   Sat Oct 17 10:35:40 2020 -0500

    correct function name in tests

commit cde2e8baa3c1c4a9f1da4135258381466b1da40a
Author: Waylon Walker <quadmx08@gmail.com>
Date:   Sat Oct 17 10:30:07 2020 -0500

    update tests

commit a355926b9d7ec4c05659adaa254beefbdb036332
Author: Waylon Walker <quadmx08@gmail.com>
Date:   Sat Oct 17 10:28:59 2020 -0500

    give name of function inside incorrect parameters error

commit 1756f5d121bd06c459560b2e982e0d7b6879e9ca
Author: Kiyohito Kunii (Kiyo) <8097799+921kiyo@users.noreply.github.com>
Date:   Fri Oct 2 15:33:09 2020 +0100

    Fix docs reference for registering `pipelines`

Fix all commits #

Now to do this for 18 other commits. I found that chaining the three commands into a bash one-liner was quite helpful. I turned off pre-commit hooks with --no-verify. I also turned off the log pager by adding --no-pager.

git rebase --continue && \
git commit --amend --reset-author --no-edit --no-verify && \
git --no-pager log -n 3

Done #

This was quick and easy for 19 commits. I have tried to loop through changes like this in the past, and it does get a bit hairy. I find its easier to just setup a one-liner and crank through them one by one.

A note on changing history… #

Since this was done in a rebase it has changed the history of the repo. This is ok to do only when you are the only person or are in close communication with everyone using the repo. One thing I have ran into is that if you do this after you submit a PR, but before its completed it duplicates your commits in a merge. For this particular change I simply closed the first PR and opened a second. If someone has a better suggestion, I would be glad to know a better way.

ReCap #

cd kedro
git config user.name "Waylon Walker"
git config user.email quadmx08@gmail.com
git log
git rebase -i HEAD~20
git log
git rebase --continue
git log
git rebase --continue && git commit --amend --reset-author --no-edit --no-verify && git --no-pager log -n 3

List the latest files to change in a git repo

2020-10-08T05:00:00Z

while read file; do echo $(git log --pretty=format:%ad -n 1 --date=raw -- $file) $file; done < <(git ls-tree -r --name-only HEAD | grep static/stories) | sort -r | head -n 3 | cut -d " " -f 3

Strip Trailing Whitespace from Git projects

2020-09-30T05:00:00Z

A common linting error thrown by various linters is for trailing whitespace. I most often use flake8. I generally have [pre-commit](https://waylonwalker.com/pre-commit-is-awesome hooks setup to strip this, but sometimes I run into situations where I jump into a project without it, and my editor lights up with errors. A simple fix is to run this one-liner.

One-Liner to strip whitespace #

bash

git grep -I --name-only -z -e '' | xargs -0 sed -i -e 's/[ \t]\+\(\r\?\)$/\1/'

read more about how pre-commit is awesome

Rename your Master Branch

2020-06-12T02:12:24Z

Rename your Master Branch

git branch -m master main
git push -u origin main

Master No More

2020-06-11T05:00:00Z

It’s been a long time coming. We use some very harsh language within tech so much sometimes that we become numb to it. It’s time to do my very small part in this movement and purge this language from my active repos starting with this blog right here.

Large Refactor At The Command Line

this post follows my method of refactoring code bases from the command line, read more about that in this article.

c-s-f #

First off browsing through the content of my blog I found many references to master. I cannot completely whole-sale find and replace each one of them, because some of them are links that I do not own. Any set of instructions got upgraded from master to main

-  git checkout master
+  git checkout main

There were countless cases of examples like this to comb through, but it feels good to have them purged of old language.

rename routes #

Following yesterdays post, I am going to rename my markdown files

/static/_redirects

shorteners #

- /gdfm              /blog/today-i-learned-git-diff-feature-master/
- /blog/gdfm         /blog/today-i-learned-git-diff-feature-master/
+ /gdfm              /blog/today-i-learned-git-diff-feature-main/
+ /blog/gdfm         /blog/today-i-learned-git-diff-feature-main/

redirect posts #

+ # master -> main
+
+ /blog/today-i-learned-git-diff-feature-master/   /blog/git-diff-feature-main/

redirect external links to repo #

- /redirects      https://github.com/WaylonWalker/waylonwalkerv2/edit/master/static/_redirects
+ /redirects      https://github.com/WaylonWalker/waylonwalkerv2/edit/main/static/_redirects

More info on refactoring your blog routes with netlify here.

“Edit This post” Links #

I literally just added “edit this post” links to my rss feed and my blog feed. This was a simple find and replace inside of my blog template and gatsby-config.js

Don’t Forget about CI #

If you have build/deploy processes that specifically run on master or not on master dont forget to change those to main. I did everything in a single commit and as soon as I pushed to main it started deploying gloriously.

name: 🌱 Deploy site

on:
  push:
    branches:
-      - master
+      - main

Now the fun part #

removing master completely

I mostly just followed this post by Scott Hanselman.

git branch -m master main
git push -u origin main

Then from GitHub go to settings>default branch> select main and accept the risk involved.

After your default is set to main, you have no use for master in your life anymore, time to purge it completely once and for all. Go to /branches and trash it.

Stop the Bleeding #

I like how Scott included this nice alias for starting from main from the beginning.

git config --global alias.new '!git init && git symbolic-ref HEAD refs/heads/main'

See the Full Diff #

If you happen to want to see the full diff of my change you can see it here.

008

2020-06-07T01:58:03Z

compare feature branch to main with git cli

git diff main..feature

006

2020-06-06T18:14:14Z

Setup pre-commit for isort

  - repo: https://github.com/asottile/seed-isort-config
    rev: v2.1.1
    hooks:
      - id: seed-isort-config
  - repo: https://github.com/pre-commit/mirrors-isort
    rev: v4.3.21
    hooks:
      - id: isort

includes automatic .isort-config

005

2020-06-06T18:12:10Z

pre-commit setup is simple

pip instal pre-commit
pre-commit sample-config > .pre-commit-config.yaml
pre-commit install
git add .
git commit -m "added pre-commit"

Try it yourself

Maintianing multiple git remotes

2020-05-07T11:56:00Z

git remote -v
git remote add gitlab <url>
git push gitlab main

Today I learned `git diff feature..main`

2020-03-03T11:58:00Z

Today I learned how to diff between two branches.

git diff feature..main

Sometimes we get a little git add . && git commit -m "WIP" happy and mistakenly commit something that we just can’t figure out. This is a good way to figure out what the heck has changed on the current branch compared to any other branch.

Example #

Let’s create a new directory, initialize git and toss some content into a readme.

mkdir git-diff
git init
echo "hello there" > readme.md
git add . && git commit -m "hello there"
cat readme.md

After all of that, we have a git repository on our local machine with a single file readme.md that contains the following.

hello there

Create a branch and ✍ edit #

Let’s checkout a new branch called Waylon and change the word there to Waylon in our readme.md file, then diff it.

git checkout -b Waylon
echo "hello Waylon" > readme.md
git add . && git commit -m "hello Waylon"
git diff

- hello there
+ hello waylon

At this point we have one commit. Things are really straightforward, and our diff will be the same between the last commit and the main branch since. Let’s make another commit by adding the date.

echo "hello waylon\n\n$(date)" > readme.md
cat readme.md
git diff

hello Waylon
+
+ Fri 13 Mar 2020 04:23:21 PM DST

👆 At this point, our diff doesn’t tell us the whole story between our current state and main, only between our current state and our last commit. Let’s commit our changes and compare our branch to main.

git add . && git commit -m "add date"
git diff main..waylon

- hello there
+ hello Waylon
+
+ Fri 13 Mar 2020 03:43:21 PM DST

Git is powerful #

I learn small tricks like this often with git. Many times I forget about it and have to come back to re-learn. Sharing my thoughts gives me a better chance of remembering.

git push without setting upstream

2020-02-04T12:18:00Z

Finally after years of hand typing out a full git push --upstream my_really_long_and_descriptive_branch_name I found there is a setting to automatcally push to the current branch. More realisitically I just did a git push let git yell at me, and copying the suggestion.

git config #

git config --global push.default current

This one setting will now git push to the current branch without yelling at you that your upstream does not match your current branch. This helps me ship chnages faster as I am constantly chnaging projects and branches.

Realistic Git Workflow

2019-05-27T00:00:00Z

My git workflow based on real life. Its not always clean and simple.

sometimes things get messy

The Clean Path #

pull 👉 branch 👉 format 👉 work👉 add 👉 commit 👉 pull 👉 rebase 👉 push

Pull #

As complicated as that seems it is pretty straight forward. When you sit down to work the first thing you do is to pull down the teams latest working “develop” branch from git.

git checkout develop
git pull

Branch #

Next create a new branch with a name that will remind you of what you are working on. For your own sanity choose something descriptive. It is easy to get too many similar branches going and forget which branch is which.

git checkout -b ingest_product_id_table

Format #

If you know which files in existance that you will be editing before you start work it is a good idea to format them in a commit early on to keep your working commits separate from formatting. This will make it easier for reviewers to distinguish from your changes and formatting fixes.

If your team agrees to a consistent formatting logic, sticks to it and always remembers to run the linting/fixing tools you should not have anything to change. But thats not what this post is about, its about the real world. People forget to run linters, some don’t care, some may not even be aware of the teams formatting guidelines. Talk to your team about these things and get on the same page.

I care about formatting, we all should. We want to put out the best work we can in our craft. Realistically though I dont really care about nit picky stuff, I just want things consistant so that it makes things easier to read without me taking the time to swap out quotes, and fix line spacing. I want a tool to do it for me, and when that tool runs I dont want it mixing in the same commit as my work.

black .
git add .
git commit -m "FIX formatted with black"

Work #

Make your changes to your code, test them, document them, clean it up, do what you do best.

add and commit #

Next you will need to stage files that have changed for commit, and commit them. This can be done in stages to make it clear what the progression was to finish the task you were assigned.

add all files

    git add .

add a single file

git add "path/to/myfile.ext"

one line commit message

Here make sure that you create clear messages so that others know. There are whole posts out there showing how to better write clear commit messages and why you should, check out those posts for more information.

git commit -m "FEAT ingested product id table on pipeline"

multi-line commit message

If you want some more information in your commit message run git commit without -m and it will pop you into your configured git editor, which is vim by default.

Super quick vim primer #

By default when you run git commit you will pop into a vim editor and may want to throw your keyboard before you figure out exactly how to get out of the damn thing. First type i to insert text. Type out your commit message. Then hit esc followed by :x. This is the most basic things you need, and will get you through a commit message. Vim is a whole topic on its own.

Integrate your changes #

Now that you have made your changes and commited them its time to integrate them into the codebase so that everyone else can see them. It is likely that time has gone by, and others have made changes to the codebase since you have, so you will want to pull those down first then switch back to your branch.

git checkout develop
git pull
git checkout ingest_product_id_table

Now you have the latest code changes and your work locally. I prefer to rebase my work with the develop branch, pretending that I started my work after all of the other changes had occurred. You can choose to merge, but I prefer not to have the extra merge commits in my PR.

git rebase develop

push #

Now its time to push out to the remote repository and create your PR.

git push --set-upstream ingest_product_id_table

Open your repository in your web browser and you should see that you have just pushed to a new branch and a button to open a Pull Request (PR).

Your Not Done yet #

Opening a PR is not a done deal, it starts the conversation to get your code approved to be merged into the develop or main branch. Your approver may have an idea to clean it up to make it more readable/maintainable, or something to make it more performant. Remember that a second set of eyes sometimes has a new set of clarity that you do not as you have seen the work from start to end. At this point they may request changes, discussion, or choose to accept and merge it in.

Realistically #

We all hit some pitfalls along the way

Things get dirty, the clean path is not always the path that is taken, but with git we can clean up our mess and make it look that way.

I started working from main/develop before branching #

Pitfall #1

This is my most common pitfall. I get really excited to start work and jump right in. Then when I go to make some commits I see that main branch staring me right in the face from my bash prompt.

stash those changes away

git stash
git checkout -b feature_branch
git stash pop

want to see what changes you have stashed away

git stash list

I committed to the wrong branch #

Pitfall #2

Create a new branch Solution #1

It is common that I just forget to switch from the main/develop branch into my feature branch before starting work. You will first need to look at your git log and determine how many commits to go back or a git hash to go back to.

CAUTION git reset --hard will kill changes and you will never get them back if you did not first put them somewhere. I myself have been burned by this command, there is no recovering from a hard reset.

git log
# note commit hash or ~n to go back to
git branch feature_branch
git reset --hard HEAD ~3
# or
git reset --hard a1b2c4d4

Move to an Existing Branch

Sometimes when juggling many different features we are in the middle of several branches and forget to switch between them. If its the case that you already have a feature_branch for the feature that you are working on, you can use this solution.

git status
# note current_branch
git checkout feature_branch
git merge current_branch
git reset --hard HEAD ~3
# or
git reset --hard a1b2c4d4

Another feature was complete before mine #

pitfall #3

This can be a big matter of preference of how to deal with this just google merge vs rebase. For this particular pitfall I prefer to rebase. When you look at the git log and commit history it will appear as if you made your changes after everyone else made theirs. I do this to clean up the PR and make it easier for the approver to read. There will be less merge commits, and less history to try to understand.

Before pushing to the remote repository

git fetch --all
# or
git checkout develop
git pull
git checkout feature_branch
# then
git rebase develop

if its your first rodeo or you are unsure how the rebase will go you can create a safty branch.

git branch saftey_feature_branch
git fetch --all
git rebase develop
git branch -D safety_feature_branch # deletes safety_feature_branch

Rewrite History with Git

2019-02-05T00:00:00Z

rebase
git commit –amend

Unstage #

git reset -- <file>

rage unstage to wipte out history of staged commit

git reset --hard <file>

Undo file #

rage quit
git reset HEAD~n
- removes modifications
- keeps hitsory of changes and undoes them
git checkout HEAD~n –
- keeps modifications
- removes history
- –SOFT
- –HARD
- –Mixed

undo n commits back #

locally before push

git reset HEAD~n

after push

git revert HEAD~n

update .gitignore #

after push

git rm -r --cached .
git commit -am "Updated .gitignore"

Update Git User

2019-01-21T00:00:00Z

This morning I log into my VCS and check activity on my projects to find that someone else has been very active on my projects fo the last few weeks. I quicklyhover over the missing avatar to find that It’s Me. What’s wrong here, why do I look like two different people throughout the day! upon further investigation I see the issue. while setting up a new terminal environment I mistyped my email address by one character. After much searching and a few failed attempts I was able to fix it by following an article no longer available (2021) from https://help.github.com/articles.

Bare Clone #

Clone the repo, note it must be a --bare clone.

git clone --bare https://github.com/user/repo.git
cd repo.git

git-author-rewrite">git-author-rewrite #

Curl down the git-author-rewrite script and edit the following variables OLD_EMAIL CORECT_NAME CORRECT_EMAIL

curl https://gist.githubusercontent.com/octocat/0831f3fbd83ac4d46451/raw/c197afe3e9ea2e4218f9fccbc0f36d2b8fd3c1e3/git-author-rewrite.sh > git-author-rewrite.sh

Run the script, and push the updates.

bash git-author-rewrite.sh
git push --force --tags origin 'refs/heads/**'

Cleanup #

Delete the --bare repo from your local machine.

cd ..
rm -rf repo.git

I hope this helps someone, or future me who needs to fix their information in git.

remove git cruft

2019-01-21T00:00:00Z

inspiration #

My original inspiration for this post came from steven ostermiller’s blog post that no longer exists from my last check in May, 2024.

https://blog.ostermiller.org/removing-and-purging-files-from-git-history/

I was able to find it on the way back machine though.

https://web.archive.org/web/20240222195617/https://blog.ostermiller.org/removing-and-purging-files-from-git-history/

git log --all --pretty=format: --name-only --diff-filter=D | sed -r 's|[^/]+$||g' | sort -u

git filter-branch --tag-name-filter cat --index-filter 'git rm -r --cached --ignore-unmatch FILE_LIST' --prune-empty -f -- --all

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --aggressive --prune=now

git push origin --force --all
git push origin --force --tags

cd MY_LOCAL_GIT_REPO
git fetch origin
git rebase
git reflog expire --expire=now --all
git gc --aggressive --prune=now

Posts tagged: git Archive

📝 Git Notes

See old revisions of one file #

Checkout an old revision of a file #

fuzzy pick a file and check out an old revision #

git name status

tea login flag

💭 You already have a git server: (Maurycy's blog)

💭 Learn to use email with git!

💭 Repository Mirrors | Forgejo – Beyond coding. We forge.

💭 Let's Make Sure Github Doesn't Become the only Option - Edward...

💭 Git Fork vs Git Clone (Animated) - YouTube

💭 Some Git poll results

<<<<<<< HEAD YOUR CODE

«««< HEAD OTHER BRANCH’S CODE

Two new shell aliases for git

trackme #

getting the branch #

rebasemain #

The Aliases #

gh repo create

want to see what this repo I created is about? #

git merge ours

update main #

update your feature branch #

start the merge #

List all git commits with GitPython

GPG signing commits over ssh

Error #

The fix #

The log in menu #

EDIT-another way #

Review Pull Requests with git worktrees

Using Git from Python

Use Case #

Installation #

Create a Repo Object #

Two interfaces #

Status #

log #

Find Deleted Files #

My Experience #

Set Your Git Pager Config

Setting the pager #

Color #

Pagers I have tried #

reset back to the default #

Configure Git to Autocorrect Your Fat Fingers

Automatically run the right one #

Fat Fingers Gone #

My config #

Git Worktrees are not so Scary

Myth #1 #

Lets make a worktree #

Myth #2 #

You can only checkout a branch in one place #

Myth #3 #

It won’t let you remove if you have changes #

RTFM #

Configure Git to Always Push to the Current Branch

fatal has no upstream branch #

Option 1: follow the instructions #

Option 2: push to the current branch without setting upstream #

Recover a lost git branch with checkout

TLDR #

Immediate Regret #

Delayed reaction #

Kinda Recent #

A lot has happened since then #

RTFM #

git find deleted files

git log –diff-filter #

git reflog –diff-filter #

get the last commit from a file #

git diff-filter

Man page #

Try it out #

Git rebase to the beginning of time

Revive files from the dead with git

caveat #

run `gitui` #

run `gitui` #