Most Git commands accept a --date= option with accepted values of relative, local, default, iso, or rfc to control how dates are displayed. For example: git show --date=local And as usual, if you Git to always display dates this way then you can set it globally with: git config --global log.date local
Merge Development (md) git config --global alias.md '!git fetch && git merge --no-ff origin/development' What it does: Fetches the latest changes from the remote and merges the origin/development branch into your current branch using a non-fast-forward merge (creates a merge commit even if a fast-forward is possible). Delete Gone Branches (db) PowerShell: git config --global alias.db '!for branch in `git branch -vv | grep ": gone]" | awk "{print \$1}"`; do git branch -D $branch; done' Bash/Git Bash: ...
Submodules See Demystifying git submodules Command to run after first cloning a repo that uses submodules: git submodule update --init --recursive if submodule has been updated on remote, then run this after git pull: git submodule update Keep fork updated git remote add upstream https://github.com/adityatelange/hugo-PaperMod.git git fetch upstream/master
Are people migrating away from GitHub? I don’t know if you’d say GitHub is enshittified, but it is striding forward in a more corporate manner. This post gives a nice concise summary of the recent complaints people have had about Github.
Today I discovered that referencing HEAD in git commands should technically always be uppercase. On case-insensitive file systems you can use lowercase head most of the time and it just works… as long as you don’t use worktrees. If you use head while in a worktree then it resolves to the head of the main worktree and not the head of the worktree you’re currently in like you would expect. ...
Git Notes: git’s coolest, most unloved feature - Tyler Cipriani It would be pretty cool if this feature was given some love. Apparently Forgejo now has first-class support for it.
As of Git 2.51 there is now a process for backing up your git stashes. The gist of it is there is now stash export command to export your stashes as a single reference and push them to a remote: git stash export --to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash and then on another machine or a different clone of the repo: git fetch origin '+refs/stashes/*:refs/stashes/*' git stash import refs/stashes/my-stash Unfortunately this process isn’t that great for regular backups but can be useful if you need easily move lots stashes to another machine. For one off stashes though, it might be easier to create a patch file.
The future of large files in Git is Git - Tyler Cipriani I’ve so far managed to avoid having to deal with Git LFS so I’m excited to see that the Git team is working on a better solution. In the mean time I’ll have to try the tip that Tyler gives with git partial clone: git clone --filter='blobs:size=100k' <repo>
An Undefeated Pull Request Template | Ashlee M Boyer This is probably the best and most thorough advice I’ve seen on how to write good pull request descriptions. So many great bits of advice and things I wanted to +1. The first goal of a pull request description is to make code review as straightforward and frictionless as possible. Even if everyone knows the code, you’re saving them time by doing the thinking for them. The code is still fresh in your mind whereas they might need to take a few minutes to recall how the feature works. ...
Today I learned how to create and apply a patch file with Git. If you want to quickly create patch a file from your current changes just run: git diff > mypatch.patch or if like me you just want specific changes then stage them and then run: git diff --cached > mypatch.patch then to apply the changes all you need is git apply mychanges.patch Unfortunately if there are conflicts then git will just give you an error: patch does not apply ...