You push, and a minute later you see it. An API key sits in .env, in a commit that is already on GitHub.
The quick fix is to delete the file and commit again. That feels like it should work. It does not, and we will see exactly why in a scratch repository.
\nThink of history as a chain where every link carries a fingerprint of the link before it. You cannot pull one link out. You have to rebuild every link that came after it.
\nThere is an order to this, and the first step is not a Git command:
\nWe will do steps 2 and 3 on a real repository and check the result with two commands. The end state looks like this:
\n$ git log --oneline -S\"FAKE-not-a-real-key\"\n$ git count-objects -vH\nsize-pack: 1.98 KiB\nDo this before anything else, and before you touch Git.
\nA key that was pushed has been seen. It may be cached somewhere, copied by a build bot, or scraped by something that watches public pushes. Rewriting history afterward does not un-see it. GitHub's own page on this says to revoke or rotate the secret first, and that doing so may be enough on its own.
\nSo open the service that issued the key, create a new one, and delete the old one. Then put the new one somewhere that Git never sees.
\nEverything after this is cleanup. The key is already dead, so we can take our time.
\nThis sets up the same mess on your machine. The folder hub.git plays the part of GitHub. Paste it into Git Bash, in an empty folder.
mkdir secret-lab && cd secret-lab\ngit init --bare -b main hub.git\ngit clone hub.git alice\ncd alice\necho 'console.log(\"hello\");' > app.js\ngit add app.js\ngit commit -m \"Add app\"\necho 'API_KEY=FAKE-not-a-real-key-123' > .env\nhead -c 3000000 /dev/urandom > db-backup.dump\ngit add .\ngit commit -m \"Add settings\"\necho 'console.log(\"v2\");' >> app.js\ngit commit -am \"Update app\"\ngit rm --cached .env db-backup.dump\nprintf '.env\\ndb-backup.dump\\n' > .gitignore\ngit add .gitignore\ngit commit -m \"Stop tracking .env\"\ngit push origin main\ncd ..\ngit clone hub.git bob\ncd alice\nThe last three lines make bob, a teammate's clone that we use near the end. It has to exist now, before the history changes. Git says You appear to have cloned an empty repository. after the first clone. That is fine, hub.git is empty at that point.
git add . is the slip. It added the key file and a 3 MB database dump, which stands in for the thing you did not mean to commit. The last commit is the quick fix: it stops tracking both files and ignores them.
Ask Git which commits ever changed that text:
\n$ git log --oneline -S\"FAKE-not-a-real-key\"\nfbe993a Stop tracking .env\n65bf43d Add settings\n-S lists the commits where the number of times the text appears went up or down. Add settings put it in. Stop tracking .env took it out. The key is still inside the older commit, and anyone can read it:
$ git show 65bf43d:.env\nAPI_KEY=FAKE-not-a-real-key-123\nReplace 65bf43d with the hash of your own Add settings commit. To find it, run the git log --oneline -S\"FAKE-not-a-real-key\" command above and copy the hash from the lower line, the older commit that added the key. For your own secret, put a few characters of the real one inside the quotes. The latest commit is clean, and the history is not.
git filter-repo is not part of Git. It is a separate Python script that Git can call as if it were a command, and it rewrites every commit in one pass. The older git filter-branch does a similar job, and we will not use it here.
The project's own install notes (read October 2026) assume you already have Git and Python. Their routes are a package manager (they name Scoop for Windows), PyPI through pipx, or downloading the single script git-filter-repo and putting it on your PATH.
What we tested: in a Python virtual environment (a private folder of Python packages), python -m pip install git-filter-repo put a git-filter-repo.exe in the environment's Scripts folder. Pip does not put that folder on your PATH. Before we added it, Git said:
$ git filter-repo --version\ngit: 'filter-repo' is not a git command. See 'git --help'.\nIn Git Bash, from the folder that holds the environment (here named venv), either of these fixes it for that window:
export PATH=\"$PWD/venv/Scripts:$PATH\"\nsource venv/Scripts/activate\nThe second one turns the whole environment on. The first one only adds the folder. Open a new window and you have to do it again.
\nThe project's INSTALL file gives two other commands, pipx install git-filter-repo and, for a package manager such as Scoop, PACKAGE_TOOL install git-filter-repo, which for Scoop reads scoop install git-filter-repo. We did not run either of those, or the manual copy, so check the INSTALL file if one fails.
To check the install, ask for the version:
\n$ git filter-repo --version\na40bce548d2c\nThat is a build hash, not a version number. pip show git-filter-repo prints Version: 2.47.0. The --sensitive-data-removal option we use needs 2.47 or newer, according to GitHub's page.
filter-repo refuses to run in a repository you have been working in. Try it in alice:
$ cd ../alice\n$ git filter-repo --sensitive-data-removal --invert-paths --path .env --path db-backup.dump\nAborting: Refusing to destructively overwrite repo history since\nthis does not look like a fresh clone.\n (expected at most one entry in the reflog for HEAD)\nGood. The rewrite throws the old history away, so it wants a copy where nothing else is at stake. Make a fresh clone and measure it first:
\n$ cd ..\n$ git clone hub.git fresh\n$ cd fresh\n$ git count-objects -vH\ncount: 13\nsize: 2.86 MiB\nin-pack: 0\npacks: 0\nsize-pack: 0 bytes\nprune-packable: 0\ngarbage: 0\nsize-garbage: 0 bytes\nThirteen loose objects, 2.86 MiB. Almost all of it is the dump. (A clone from GitHub arrives as one pack, so there you would read size-pack instead of size.)
Now the rewrite:
\ngit filter-repo --sensitive-data-removal --invert-paths --path .env --path db-backup.dump\nHere is what each part does:
\n--path .env --path db-backup.dump names the two files.--invert-paths means everything except those paths. Leave it out and --path does the opposite: it keeps only those files and drops the rest. We ran that by mistake on purpose, and the repository kept only the commits that touched .env.--sensitive-data-removal fetches every ref from origin first, so no branch is left holding the old history, and it prints the follow-up steps.NOTICE: Fetching all refs from origin to make sure we rewrite\n all history that may reference the sensitive data, via\n git fetch -q --prune --update-head-ok --refmap \"\" origin +refs/*:refs/*\nParsed 4 commits\nHEAD is now at 35cccfa Stop tracking .env\n\nNew history written in 1.42 seconds; now repacking/cleaning...\nYou rewrote 4 (of 4) commits.\n\nNOTE: First Changed Commit(s) is/are:\n 25b989967cec4c5eb38a6818ae42853374f55c8a\nNOTE: LFS object orphaning not checked (LFS not in use)\n\nRepacking your repo and cleaning out old unneeded objects\nCompletely finished after 2.70 seconds.\n\nNEXT STEPS FOR YOUR SENSITIVE DATA REMOVAL:\n * ...\nThe NEXT STEPS list that follows is long. It covers what we do next. Keep the First Changed Commit hash, because GitHub support asks for it.
$ git log --oneline\n35cccfa Stop tracking .env\n648e253 Update app\n1de2032 Add app\nFour commits became three. Add settings only added the two files, so once they were gone it had nothing left and Git dropped it. Every hash is new, even the first one, Add app, which never touched the secret. A commit's hash covers its parent, and the first commit changed first.
Run the same search again, then measure:
\n$ git log --oneline -S\"FAKE-not-a-real-key\"\n$ git count-objects -vH\ncount: 0\nsize: 0 bytes\nin-pack: 9\npacks: 1\nsize-pack: 1.98 KiB\nThe search prints nothing. The repository went from 2.86 MiB to 1.98 KiB. Your sizes will differ if you drop a different file, and a small secret on its own would not move the number much.
\nThe server still has the old commits. Replace them from inside fresh, the clone we just rewrote (alice is untouched, and pushing from it would do nothing useful):
$ git push --force --mirror origin\n + fbe993a...35cccfa main -> main (forced update)\n--force lets the push overwrite a branch that is not a descendant of the old one. --mirror makes the server match this clone for every branch and tag, so no old tag keeps the key alive. GitHub's page adds that this command cannot update the refs/pull/ references, which GitHub marks read-only, and that you may need to turn off branch protection for a moment if a protected branch rejects the push.
Notice that origin is still configured here. That is --sensitive-data-removal at work. Without it, filter-repo removes the origin remote after a rewrite, and you have to add it back before you can push.
Take bob, who cloned before the rewrite. We made his clone in the build box, with git clone hub.git bob. bob sits next to fresh, so ../bob reaches it. He runs the habit of a lifetime:
$ cd ../bob\n$ git pull\n + fbe993a...35cccfa main -> origin/main (forced update)\nfatal: refusing to merge unrelated histories\nGit is right. The old history and the new one share no commit. That refusal is protection. Bob can push past it, and this is how the secret comes back:
\ngit pull --no-rebase --allow-unrelated-histories --no-edit\ngit log --oneline -S\"FAKE-not-a-real-key\"\nThe search lists the old commits again. One merge commit reintroduced everything we purged. GitHub's page warns about the same thing and says branches built on the old history should be rebased onto the new one, never merged.
\nThe simple fix is to discard the old clone and clone again:
\ncd ..\ngit clone hub.git bob-again\n$ git log --oneline -S\"FAKE-not-a-real-key\"\n$\nIf Bob has unpushed work, he copies those files out first, re-clones, and puts them back. The filter-repo manual describes a way to clean an existing clone, but a fresh clone has fewer ways to go wrong.
\nWe tested our own hub.git, which is a plain bare repository. After the force-push, the old commit was still in it:
$ cd hub.git\n$ git cat-file -t fbe993a\ncommit\n(fbe993a is our old tip, the one the force-push replaced. In your push output it is the first hash in the + old...new line.)
The server had 17 loose objects and 2.86 MiB, the old ones included. They are unreachable from any branch now, but they are still on disk. They go away when the server runs garbage collection, and by default git gc only deletes unreachable objects that are older than two weeks.
GitHub's page lists more, and we cannot test any of it from here:
\nFirst Changed Commit hash. The page says support only helps with removal when rotating the credential cannot take care of the risk. That is one more reason step 1 comes first.That page is the source for all four, read in October 2026. Things like this change, so read the current version before you send anyone to it.
\ngit maintenance fits#git maintenance runs housekeeping tasks that Git skips during everyday commands, such as gc, commit-graph and prefetch. git maintenance start schedules them hourly in the background; on Windows it uses the Task Scheduler (schtasks).
It does not remove a secret quickly. On a copy of our hub.git, we ran:
git maintenance run --task=gc\ngit cat-file -t fbe993a\nThe commit was still there. It was packed, but not pruned, because it was younger than two weeks. Only this removed it:
\n$ git reflog expire --expire=now --all\n$ git gc --prune=now\n$ git cat-file -t fbe993a\nfatal: Not a valid object name fbe993a\n--prune=now deletes unreachable objects of any age. Git's manual warns it can corrupt a repository if another process is writing to it at the same moment, so it belongs on a repository nobody is using. On GitHub you cannot run it. That is the job of the support request above.
This is the same loop in six commands. The practice repository is the one we just built: the key is in an old commit, origin is set, and the key has already been rotated.
Type these commands in order, in a fresh clone of the leaked repository:
\ngit log --oneline -S\"FAKE-not-a-real-key\". It lists Add settings and Stop tracking .env.git count-objects -vH. It reports 13 objects and 2.86 MiB.git filter-repo --sensitive-data-removal --invert-paths --path .env --path db-backup.dump. Every commit gets a new hash.git count-objects -vH. It reports 9 objects and 1.98 KiB.git push --force --mirror origin. A normal push is rejected.Try the interactive Git practice terminal on the original article.
Two things to try in the terminal: leave out --invert-paths in step 3 and read the message, and run a plain git push origin main in step 6.
You pushed a key in .env, then deleted the file in your next commit and pushed again. Is the key still in the repository?
git show <commit>:.envgit gcAnswer: A. Yes, the older commit still holds it, and anyone can read it with git show <commit>:.env
The newest commit is clean, but history keeps every older commit. git log -S\"<text>\" lists the commits where the text was added and removed.
On a fresh clone, you run git filter-repo --path .env with no --invert-paths. What happens to the history?
.env are gone.env is removed from history--invert-pathsAnswer: A. Only the files you named are kept, so the commits that never touched .env are gone
In our test, the repository kept two commits, the ones that touched .env, and the working tree was empty. --invert-paths flips the meaning to \"everything except these\".
After you force-push a rewritten history, a teammate who cloned earlier runs git pull and then git pull --allow-unrelated-histories. What does the second command do to the secret?
Answer: A. It merges the old history back in, so the secret is reachable again
\nIn our test the search listed the old commits again after that merge. A teammate with an old clone should re-clone, or rebase onto the new history, and never merge.
\nChallenge: remove the key and keep the dump
\nSometimes the file has to stay in history and only the text has to go. git filter-repo can replace text with --replace-text, which takes a file of replacements.
Build the leaked repository again in a new, empty folder (the box above does the whole thing). Make a fresh clone of its hub.git. Outside the clone, create expressions.txt with one line:
FAKE-not-a-real-key-123==>REMOVED\nThen run git filter-repo --sensitive-data-removal with --replace-text pointing at that file.
Expected result: all three of these hold in the clone.
\n$ git log --oneline -S\"FAKE-not-a-real-key\"\n$ git log --oneline\n(four commits, with new hashes)\n$ git show HEAD~2:.env\nAPI_KEY=REMOVED\ngit clone hub.git fresh\ncd fresh\ngit filter-repo --sensitive-data-removal --replace-text ../expressions.txt\nThe text is replaced inside every old copy of .env, and all four commits are still there, with new hashes. The dump was never touched, so git count-objects -vH still shows about 2.86 MiB in size-pack. Replacing text hides the key. It does not shrink anything.
git log -S\"<text>\" finds every commit that added or removed it.git filter-repo is a separate install that needs Python. It runs only in a fresh clone, and --sensitive-data-removal --invert-paths --path <file> removes a file from every commit.git push --force --mirror origin replaces every branch and tag. Teammates re-clone, or rebase onto the new history. A merge brings the secret back.git maintenance alone does not do that within two weeks.Rotating the key is what protects you. Rewriting history only removes the copies that anyone could still read.
\nJoin the discussion on the original article.
\n", "content_text": "You Committed a Secret: What to Do, in Order.\nCanonical: https://mnixblog.netlify.app/you-committed-a-secret-what-to-do-in-order/\nCancel the Key First, Then Clean Up the History, and Know What Stays on the Server\nYou push, and a minute later you see it. An API key sits in .env, in a commit that is already on GitHub.\nThe quick fix is to delete the file and commit again. That feels like it should work. It does not, and we will see exactly why in a scratch repository.\nThink of history as a chain where every link carries a fingerprint of the link before it. You cannot pull one link out. You have to rebuild every link that came after it.\nThere is an order to this, and the first step is not a Git command:\nRevoke or rotate the key.\nRewrite history so the key is in no commit.\nForce-push the new history.\nGet your teammates onto it.\nAsk the host about the copies it keeps.\nWe will do steps 2 and 3 on a real repository and check the result with two commands. The end state looks like this:\n$ git log --oneline -S\"FAKE-not-a-real-key\"\n$ git count-objects -vH\nsize-pack: 1.98 KiB\nNote:\nEvery command and output here comes from Git 2.45.2 on Windows 11, run in Git Bash, with git-filter-repo 2.47.0. The secret is fake on purpose: FAKE-not-a-real-key-123. Never practice with a real one. The commit hashes you get will differ from ours every time, because a hash covers the commit time. Never type one of ours. Copy yours from your own git log.\nStep 1: make the key worthless\nDo this before anything else, and before you touch Git.\nA key that was pushed has been seen. It may be cached somewhere, copied by a build bot, or scraped by something that watches public pushes. Rewriting history afterward does not un-see it. GitHub's own page on this says to revoke or rotate the secret first, and that doing so may be enough on its own.\nSo open the service that issued the key, create a new one, and delete the old one. Then put the new one somewhere that Git never sees.\nEverything after this is cleanup. The key is already dead, so we can take our time.\nBuild the leak yourself\nThis sets up the same mess on your machine. The folder hub.git plays the part of GitHub. Paste it into Git Bash, in an empty folder.\nYou run git pull and Git answers like this:
$ git pull\nfatal: Need to specify how to reconcile divergent branches.\nIt also prints a dozen lines of hints. They tell you to set a config value, and they do not say where that value is kept or whose settings you are about to change.
\nIn this article, we are going to read Git's settings, work out which file each one comes from, and set a short list of defaults, each one tied to a message like the one above. By the end, one command will tell you where every setting lives:
\ngit config --list --show-origin\nWe will also write a few aliases and decide which ones are safe to keep.
\n\nGit reads settings from several files and layers them. The ones you will touch are these:
\n| Scope | Flag | File | Applies to |
|---|---|---|---|
| system | --system | etc/gitconfig inside the Git install | every user on the machine |
| global | --global | .gitconfig in your home folder | every repository you use |
| local | --local (the default when you write) | .git/config in the repository | that repository only |
When the same setting appears in more than one file, the narrower scope wins.
\nTo see that without touching your real settings, point Git at a throwaway global file. In Git Bash:
\nexport GIT_CONFIG_GLOBAL=\"$PWD/.gitconfig\"\nexport GIT_CONFIG_NOSYSTEM=1\nGIT_CONFIG_GLOBAL replaces your global file for this terminal window only. GIT_CONFIG_NOSYSTEM=1 ignores the system file. Close the window and your own settings are back.
Now set an email twice, once globally and once in a repository:
\ngit config --global user.name \"Ada Example\"\ngit config --global user.email \"ada@home.example\"\ngit init -q demo && cd demo\ngit config user.email \"ada@work.example\"\nAsk Git for everything it knows, and where it learned it. I left out the core.* lines that git init writes into .git/config:
$ git config --list --show-origin\nfile:C:/.../.gitconfig\tuser.name=Ada Example\nfile:C:/.../.gitconfig\tuser.email=ada@home.example\nfile:.git/config\tuser.email=ada@work.example\nThe left column is the file and the right column is the setting. The email appears twice, once from each file.
\nAsk for the one that counts:
\n$ git config user.email\nada@work.example\n\n$ git config --show-scope --show-origin user.email\nlocal\tfile:.git/config\tada@work.example\nThe local file won. --show-scope adds the scope name, so you do not have to guess from the path.
If a setting behaves strangely, this is the first command to run. A value you forgot you set three years ago shows up here with its file name next to it.
\nTwo more commands finish the picture. git config --global --edit opens the global file in your editor, and git config --global --unset user.email removes one setting.
Every default below has a message it answers. We ran each one against a pretend remote, origin.git, with two clones standing in for two people.
Alice pushes a commit. Bob commits locally without pulling first, then runs git pull. Here is Bob's screen, with the hints cut out:
$ git pull\nFrom .../origin\n 9afce9f..d953b3d main -> origin/main\n...\nfatal: Need to specify how to reconcile divergent branches.\nGit will not pick between a merge and a rebase for you. The hint lists three ways to answer. Two of them are useful defaults:
\n$ git -c pull.ff=only pull\nfatal: Not possible to fast-forward, aborting.\n\n$ git -c pull.rebase=true pull\nSuccessfully rebased and updated refs/heads/main.\n-c name=value applies a setting to one command and nothing else, which is a safe way to try a default before keeping it.
pull.ff only pulls only when the pull is a straight line, and stops otherwise. You then choose to merge or rebase yourself. pull.rebase true always replays your local commits on top of what arrived, which gave Bob this history:
* 751c288 bob change\n* d953b3d alice change\n* 9afce9f start\nEither one removes the surprise. Pick one, and set it with --global:
git config --global pull.ff only\nA new branch has no upstream yet, so the first plain git push fails:
$ git push\nfatal: The current branch feature/x has no upstream branch.\nTo push the current branch and set the remote as upstream, use\n\n git push --set-upstream origin feature/x\nTurn on the setting, and the same command works:
\n$ git config --global push.autoSetupRemote true\n$ git push\nbranch 'feature/x' set up to track 'origin/feature/x'.\n * [new branch] feature/x -> feature/x\nThe branch is now tracking origin/feature/x, so git status -sb starts with ## feature/x...origin/feature/x. This setting needs Git 2.37 or newer. It assumes the branch keeps the same name on the remote, which is the usual case on GitHub.
When a branch is deleted on GitHub, your copy of its pointer, origin/feature/x, stays behind. Alice's list after Bob deleted feature/x on the remote:
$ git fetch\n$ git branch -r\n origin/feature/x\n origin/main\nA plain fetch does not remove it. With --prune, it does:
$ git fetch --prune\n - [deleted] (none) -> origin/feature/x\n$ git branch -r\n origin/main\nfetch.prune true makes every fetch behave that way. It only removes those remote pointers. A local branch of the same name stays, and Git marks it:
$ git branch -vv\n* main d953b3d [origin/main] alice change\n y ea11253 [origin/y: gone] y\ngone is your cue that the branch was merged or deleted upstream.
git commit --fixup <commit> creates a commit titled fixup! <that commit's title>. Without help, an interactive rebase leaves it at the end:
$ git rebase -i main\n$ git log --oneline\n3bb5134 fixup! Add b\n8ae88bd Add c\nd42c68b Add b\nc5773f4 Add a\nWith rebase.autoSquash on, the same command folds it into its target:
$ git config --global rebase.autoSquash true\n$ git rebase -i main\n$ git log --oneline\n4b423fe Add c\n883a054 Add b\nc5773f4 Add a\nThe Git manual says this setting applies to interactive mode. The full workflow is in Interactive Rebase, Done Properly.
\nSay step2 is built on step1, and main moves. Rebase step2 onto main and step1 is left behind:
$ git rebase main\n$ git log --oneline --graph --all --decorate\n* c628fd7 (HEAD -> step2) step 2\n* 2477d66 step 1\n* 2f96efb (main) main moves\n| * 545b7ce (step1) step 1\n|/\n* 2502ebe Add a\nWith rebase.updateRefs true, the same rebase also moves step1:
Successfully rebased and updated refs/heads/step2.\nUpdated the following refs with --update-refs:\n\trefs/heads/step1\nThis needs Git 2.38 or newer. On 2.45.2 it worked for a plain git rebase main, not only with -i.
git config --global merge.conflictStyle zdiff3\nThis adds the original text to conflict markers and trims lines both sides share. It needs Git 2.35 or newer.
\nAn alias is a short name for a longer command, stored in config. They live in the same files, so --show-origin lists them too.
git config --global alias.st \"status -sb\"\ngit config --global alias.lg \"log --oneline --graph --decorate\"\ngit config --global alias.cm \"commit -m\"\ngit config --global alias.unstage \"restore --staged\"\nThey behave like built-in commands:
\n$ git st\n## main\nM a.txt\n\n$ git lg\n* 80e12e5 (HEAD -> main) two\n* 69ce328 one\n\n$ git config --get-regexp '^alias\\.'\nalias.st status -sb\nalias.lg log --oneline --graph --decorate\nalias.cm commit -m\nalias.unstage restore --staged\nGit does not let an alias replace a command it already has. We set one anyway:
\n$ git config --global alias.status \"log --oneline\"\n$ git status\nOn branch main\nnothing to commit, working tree clean\nThe built-in git status still ran. So an alias cannot hide a real command, and a new name is always safe to try.
A leading ! runs the rest as a shell command:
$ git config --global alias.who '!git config user.name'\n$ git who\nAda Example\nOn Windows that shell is the one bundled with Git. Anything you put after ! is a script you maintain, so keep those few.
The danger in an alias is not what it does. It is that it hides what it does, at the exact moment you stop reading.
\n$ git config --global alias.undo \"reset --hard HEAD~1\"\n$ git undo\nHEAD is now at 69ce328 one\nThat discarded the commit named two. It was recoverable only because the reflog remembers it:
$ git reflog\n69ce328 HEAD@{0}: reset: moving to HEAD~1\n80e12e5 HEAD@{1}: commit: two\ngit reset --hard 80e12e5 printed HEAD is now at 80e12e5 two and the commit was back. The lesson is about hiding --hard behind a friendly word.
The same goes for alias.pushf \"push --force\". It works, and git help pushf politely says 'pushf' is aliased to 'push --force'. A name that sounds routine makes a force-push routine.
If you want one, alias --force-with-lease instead. We amended a commit in one clone while someone else pushed to the same branch from another. The lease noticed:
$ git push --force-with-lease origin main\n ! [rejected] main -> main (stale info)\nA plain git push --force in the same spot went through (+ c3c5e08...2606a78 main -> main (forced update)) and replaced the other person's commit.
A fair rule: alias commands that read (status, log, diff) freely, and think twice before aliasing anything that deletes or overwrites.
Two settings already sit in the system file. We can ask Git where they came from. These are from the Git for Windows install on this machine:
\n$ git config --system --show-origin --list\nfile:.../Git/etc/gitconfig\tcore.autocrlf=true\nfile:.../Git/etc/gitconfig\tcore.symlinks=true\nfile:.../Git/etc/gitconfig\tcredential.helper=manager\nI filtered that to three lines.
\ncore.autocrlf=true converts line endings in both directions: files get Windows endings (CRLF) in your folder and Unix endings (LF) in the repository. You see it as a warning:
$ git -c core.autocrlf=true add notes.txt\nwarning: in the working copy of 'notes.txt', LF will be replaced by CRLF the next time Git touches it\nWith core.autocrlf=input or false, the same git add prints nothing.
To see what is really stored, git ls-files --eol lists the line endings in the index (i/) and in your folder (w/). For a Windows-style file in a repository that has a .gitattributes file containing * text=auto:
$ git ls-files --eol win.txt\ni/lf w/crlf attr/text=auto \twin.txt\nThe index holds LF, the folder holds CRLF. A .gitattributes file is committed with the repository, so every clone sees the same rule. A config setting exists only on the machine that has it.
credential.helper=manager is Git Credential Manager, the helper that Git for Windows sets up, and it is what remembers your sign-in for HTTPS remotes. On this machine git credential-manager --version printed 2.5.0+d34930736e131ad80e5690e5634ced1808aff3e2. If a push asks for a password every time, check this setting first, with --show-origin so you know which file overrides it.
Here is the tour in seven commands. Type them one at a time.
\nType these commands in order, in a practice folder:
\ngit config --list --show-origin. The left column is the file; where a name repeats, the narrower scope wins.git config --show-origin user.email. It prints the local file, .git/config.git config --global push.autoSetupRemote true.git config --global fetch.prune true.git config --global pull.ff only; git config --global pull.rebase true and git config --global pull.rebase false (merge) also answer Git's question.log --oneline --graph --decorate. Try git config --global alias.lg \"log --oneline --graph --decorate\".git config --global --unset alias.lg.Try the interactive Git practice terminal on the original article.
Two things worth trying: ask for a hint, and answer step 5 with the rebase setting.
\nuser.email is set in your global file and again in a repository's .git/config. In that repository, which value does git config user.email print?
.git/configAnswer: A. The one from .git/config
The narrower scope wins. git config --show-scope --show-origin user.email prints local file:.git/config and the value.
You run git config --global alias.status \"log --oneline\" and then git status. What happens?
status and ignores the aliasgit log --onelineAnswer: A. Git runs the built-in status and ignores the alias
Git does not let an alias replace an existing command. In our run, git status printed On branch main as usual.
What does fetch.prune true remove?
origin/feature/x, when the branch is gone from the remoteAnswer: A. Remote-tracking pointers such as origin/feature/x, when the branch is gone from the remote
Only the origin/... pointers go. A local branch stays, and git branch -vv marks it [origin/y: gone].
Challenge: find where it lives
\nInside any repository, set pull.rebase for that repository only, then find out which file holds it.
Expected result:
\n$ git config --show-origin pull.rebase\nfile:.git/config\ttrue\nIf it printed a path outside .git, you set it with --global.
git config --list --show-origin shows every setting and the file behind it. --show-scope names the scope.-c name=value tries a setting for one command only.pull.ff only or pull.rebase true ends the divergent pull error. push.autoSetupRemote (2.37) sets upstream on the first push. fetch.prune removes pointers to deleted remote branches.rebase.autoSquash places fixups. rebase.updateRefs (2.38) moves stacked branches. merge.conflictStyle zdiff3 (2.35) shows the original text inside a conflict.--hard or --force.core.autocrlf and credential.helper come from the install. .gitattributes is the team's rule.git config --list --show-origin now tells us where every setting lives, and which one wins.
Join the discussion on the original article.
\n", "content_text": "Make Git Yours.\nCanonical: https://mnixblog.netlify.app/make-git-yours-config-and-aliases/\nConfig Scopes, Safe Defaults, and Aliases Worth Having\nYou run git pull and Git answers like this:\n$ git pull\nfatal: Need to specify how to reconcile divergent branches.\nIt also prints a dozen lines of hints. They tell you to set a config value, and they do not say where that value is kept or whose settings you are about to change.\nIn this article, we are going to read Git's settings, work out which file each one comes from, and set a short list of defaults, each one tied to a message like the one above. By the end, one command will tell you where every setting lives:\ngit config --list --show-origin\nWe will also write a few aliases and decide which ones are safe to keep.\nNote:\nEverything here ran on Git 2.45.2 on Windows 11, in Git Bash. Where a setting needs a newer Git, the text says so. In the output I replaced long scratch folder names with ....\nWhere a setting lives\nGit reads settings from several files and layers them. The ones you will touch are these:\nScope\nFlag\nFile\nApplies to\nsystem\n--system\netc/gitconfig inside the Git install\nevery user on the machine\nglobal\n--global\n.gitconfig in your home folder\nevery repository you use\nlocal\n--local (the default when you write)\n.git/config in the repository\nthat repository only\nWhen the same setting appears in more than one file, the narrower scope wins.\nTo see that without touching your real settings, point Git at a throwaway global file. In Git Bash:\nexport GIT_CONFIG_GLOBAL=\"$PWD/.gitconfig\"\nexport GIT_CONFIG_NOSYSTEM=1\nGIT_CONFIG_GLOBAL replaces your global file for this terminal window only. GIT_CONFIG_NOSYSTEM=1 ignores the system file. Close the window and your own settings are back.\nNow set an email twice, once globally and once in a repository:\ngit config --global user.name \"Ada Example\"\ngit config --global user.email \"ada@home.example\"\ngit init -q demo && cd demo\ngit config user.email \"ada@work.example\"\nAsk Git for everything it knows, and where it learned it. I left out the core.* lines that git init writes into .git/config:\n$ git config --list --show-origin\nfile:C:/.../.gitconfig\tuser.name=Ada Example\nfile:C:/.../.gitconfig\tuser.email=ada@home.example\nfile:.git/config\tuser.email=ada@work.example\nThe left column is the file and the right column is the setting. The email appears twice, once from each file.\nAsk for the one that counts:\n$ git config user.email\nada@work.example\n$ git config --show-scope --show-origin user.email\nlocal\tfile:.git/config\tada@work.example\nThe local file won. --show-scope adds the scope name, so you do not have to guess from the path.\nIf a setting behaves strangely, this is the first command to run. A value you forgot you set three years ago shows up here with its file name next to it.\nTwo more commands finish the picture. git config --global --edit opens the global file in your editor, and git config --global --unset user.email removes one setting.\nSix defaults that each stop one annoyance\nEvery default below has a message it answers. We ran each one against a pretend remote, origin.git, with two clones standing in for two people.\npull.ff: stop guessing on a divergent pull\nAlice pushes a commit. Bob commits locally without pulling first, then runs git pull. Here is Bob's screen, with the hints cut out:\n$ git pull\nFrom .../origin\n9afce9f..d953b3d main -> origin/main\n...\nfatal: Need to specify how to reconcile divergent branches.\nGit will not pick between a merge and a rebase for you. The hint lists three ways to answer. Two of them are useful defaults:\n$ git -c pull.ff=only pull\nfatal: Not possible to fast-forward, aborting.\n$ git -c pull.rebase=true pull\nSuccessfully rebased and updated refs/heads/main.\n-c name=value applies a setting to one command and nothing else, which is a safe way to try a default before keeping it.\npull.ff only pulls only when the pull is a straight line, and stops otherwise. You then choose to merge or rebase yourself. pull.rebase true always replays your local commits on top of what arrived, which gave Bob this history:\n* 751c288 bob change\n* d953b3d alice change\n* 9afce9f start\nEither one removes the surprise. Pick one, and set it with --global:\ngit config --global pull.ff only\npush.autoSetupRemote: stop typing --set-upstream\nA new branch has no upstream yet, so the first plain git push fails:\n$ git push\nfatal: The current branch feature/x has no upstream branch.\nTo push the current branch and set the remote as upstream, use\ngit push --set-upstream origin feature/x\nTurn on the setting, and the same command works:\n$ git config --global push.autoSetupRemote true\n$ git push\nbranch 'feature/x' set up to track 'origin/feature/x'.\n* [new branch] feature/x -> feature/x\nThe branch is now tracking origin/feature/x, so git status -sb starts with ## feature/x...origin/feature/x. This setting needs Git 2.37 or newer. It assumes the branch keeps the same name on the remote, which is the usual case on GitHub.\nfetch.prune: stop seeing branches that are gone\nWhen a branch is deleted on GitHub, your copy of its pointer, origin/feature/x, stays behind. Alice's list after Bob deleted feature/x on the remote:\n$ git fetch\n$ git branch -r\norigin/feature/x\norigin/main\nA plain fetch does not remove it. With --prune, it does:\n$ git fetch --prune\n- [deleted] (none) -> origin/feature/x\n$ git branch -r\norigin/main\nfetch.prune true makes every fetch behave that way. It only removes those remote pointers. A local branch of the same name stays, and Git marks it:\n$ git branch -vv\n* main d953b3d [origin/main] alice change\ny ea11253 [origin/y: gone] y\ngone is your cue that the branch was merged or deleted upstream.\nrebase.autoSquash: fixups land where they belong\ngit commit --fixupSomebody commits a .env file with a real password in it. Nobody notices until it is pushed.
You can write a rule for that in a README. You can mention it in review. Or you can make Git refuse the commit before it exists.
\nA hook is a script that Git runs at a fixed moment, such as just before a commit is created. If the script exits with an error, Git stops.
\nWe will write two hooks, make them part of the repository so a teammate gets them, and then find out exactly how to get around them, because that decides what hooks are for. This is the result, and it does not promise more than it shows:
\n$ git commit -m \"Add env\"\npre-commit: refusing to commit a .env file.\nEvery repository starts with a .git/hooks folder full of examples:
$ ls .git/hooks\napplypatch-msg.sample\ncommit-msg.sample\nfsmonitor-watchman.sample\npost-update.sample\npre-applypatch.sample\npre-commit.sample\npre-merge-commit.sample\npre-push.sample\npre-rebase.sample\npre-receive.sample\nprepare-commit-msg.sample\npush-to-checkout.sample\nsendemail-validate.sample\nupdate.sample\nGit ignores anything ending in .sample. To turn one on, you make a file with the hook's name and no extension: pre-commit, not pre-commit.sh.
The two we will write:
\npre-commit runs before Git asks for a commit message. It can look at what is staged. A non-zero exit stops the commit.commit-msg runs after you write the message. Git gives it the path of the file that holds the message.A hook is just a script. This one stops a .env file from being added:
#!/bin/sh\n# Stop a .env file from being added to a commit.\nif git diff --cached --name-only --diff-filter=AM | grep -q \"\\.env$\"; then\n echo \"pre-commit: refusing to commit a .env file.\"\n exit 1\nfi\ngit diff --cached --name-only lists the files in the staging area. --diff-filter=AM keeps only those that are Added or Modified. Without that part, the hook has a bug we hit in our test: a commit that removes .env from Git also lists .env, so the hook blocked the very commit that fixed the problem.
$ git commit -m \"Stop tracking env\"\npre-commit: refusing to commit a .env file.\nWith --diff-filter=AM, the same commit went through:
[main 6aa0a43] Stop tracking env\n 1 file changed, 1 deletion(-)\n delete mode 100644 .env\nThe first line, #!/bin/sh, is the shebang: it names the program that runs the file. Windows has no /bin/sh, and Git for Windows brings its own. Git runs hooks with that bundled shell, so the hook works no matter which terminal you start Git from. We committed from Git Bash and from PowerShell, and in both the hook ran and refused.
The executable bit is the other thing everybody asks about. On Linux and macOS, a hook must be executable or Git skips it. On Windows, there is no such bit on the file system. In our test, chmod -x on a hook in .git/hooks changed nothing: ls -l still showed -rwxr-xr-x, and the hook still ran. So on Windows, you do not need chmod for the hook to run for you.
It matters when a teammate on Linux or macOS gets your hook through the repository. That comes next.
\n.git/hooks is inside .git, and .git is never part of a clone. A fresh clone has the samples and none of your hooks. We check, in a clone of the same project:
$ git config core.hooksPath\n$ ls -A .git/hooks | grep -c sample\n14\nThe setting prints nothing, so it is not set. To share the hooks, we move them into a folder that is tracked, .githooks, and tell Git to look there:
$ git config core.hooksPath .githooks\n$ git config core.hooksPath\n.githooks\nTwo details:
\n.git/config, which is not shared either. Every person runs that one command once, or a setup script does. In our test, a teammate's fresh clone had the .githooks folder, and a commit with a .env in it went straight through, because the setting was not there yet.100644 by default on Windows. Make them 100755, so a teammate on Linux or macOS gets runnable scripts:$ git ls-files -s .githooks/pre-commit\n100644 d9a4c991b07dbd9b526df46c0956c7b5ac972df2 0\t.githooks/pre-commit\n$ git update-index --chmod=+x .githooks/pre-commit\n$ git ls-files -s .githooks/pre-commit\n100755 d9a4c991b07dbd9b526df46c0956c7b5ac972df2 0\t.githooks/pre-commit\ngit add --chmod=+x <file> does the same thing when the file is new. After a commit and a push, the teammate runs the one config command, and:
$ git commit -m \"Add env from clone with hooksPath\"\npre-commit: refusing to commit a .env file.\nTo run a hook by hand without committing, git hook run pre-commit runs the same script and exits with its status.
The second hook reads the message file Git passes as $1. This one keeps the first line short:
#!/bin/sh\n# commit-msg gets the message file as $1. Keep the first line short.\nif [ \"$(head -n 1 \"$1\" | wc -c)\" -gt 51 ]; then\n echo \"commit-msg: first line is longer than 50 characters.\"\n exit 1\nfi\nwc -c counts the newline too, which is why the limit is 51.
$ git commit -m \"This subject line is much longer than fifty characters in total\"\ncommit-msg: first line is longer than 50 characters.\n$ git commit -m \"Short line\"\n[main 958c11f] Short line\n 1 file changed, 1 insertion(+)\nKeep hooks like these quick and narrow. A hook that takes a minute will be skipped by everyone, and it will be right to be.
\nSometimes the hook is wrong, or the file really is fine. --no-verify skips the pre-commit and commit-msg hooks for that one commit:
$ git commit --no-verify -m \"Add env anyway\"\n[main bf37352] Add env anyway\n 1 file changed, 1 insertion(+)\n create mode 100644 .env\n-n is the short form. Git did not ask for a reason.
Keep this part in mind.
\n--no-verify is one flag, and Git does not ask why.git clone. Without the core.hooksPath command in each clone, they do not run. We saw a commit with a .env go through in a fresh clone.So a hook is a courtesy to the person committing: it tells them early, while the fix is cheap. It is not a gate. A check that must hold for the whole team has to run on the server, in CI or in branch protection, where nobody can pass a flag to skip it. This article does not test either of those.
\nThe practical rule: put the fast, friendly checks in hooks and the checks you cannot live without in CI. Run the same script in both if you can.
\nHere is the whole loop in six commands. The .githooks folder is already in the repository, with a pre-commit hook that refuses a .env file, and one is already staged. Type them one at a time.
Type these commands in order, in a practice folder:
\ngit config core.hooksPath .githooks. This is stored in your clone's .git/config, so every clone needs it once.git config core.hooksPath. It prints .githooks.git commit -m \"Add env\". Git prints pre-commit: refusing to commit a .env file. and creates no commit.git commit --no-verify -m \"Add env anyway\". -n is the short form. Git does not ask why.git update-index --chmod=+x .githooks/pre-commit. git add --chmod=+x .githooks/pre-commit does the same.git ls-files -s .githooks/pre-commit. The mode column shows 100755, where 100644 means not executable.Try the interactive Git practice terminal on the original article.
Two things worth trying in the terminal: run step 3 before step 1 and see what the commit does, and use git commit -n in step 4.
Challenge: one more file type
\nChange the pre-commit hook so it also refuses a .pem file, because a private key is no better than a password. Removing a .pem file from Git must still work.
Expected result: with core.hooksPath set, git commit -m \"Add key\" with secret.pem staged prints pre-commit: refusing to commit a .env or .pem file. and makes no commit. After --no-verify has let the file in, git rm secret.pem followed by git commit -m \"Stop tracking key\" goes through.
#!/bin/sh\n# Stop a .env or .pem file from being added to a commit.\nif git diff --cached --name-only --diff-filter=AM | grep -Eq \"\\.(env|pem)$\"; then\n echo \"pre-commit: refusing to commit a .env or .pem file.\"\n exit 1\nfi\n-E turns on extended patterns, so (env|pem) works. Keep --diff-filter=AM, or the commit that removes the key is refused too.
You write a pre-commit hook in .git/hooks, push your work, and a teammate clones the repository. Does the hook run for them?
.git is not part of a clone, so they get only the sample hooksAnswer: A. No, .git is not part of a clone, so they get only the sample hooks
In our test, a fresh clone had 14 .sample files and core.hooksPath was unset. A tracked folder plus git config core.hooksPath in each clone is how you share hooks.
What does git commit --no-verify skip?
pre-commit and commit-msg hooks for that commitAnswer: A. The pre-commit and commit-msg hooks for that commit
--no-verify only affects hooks on your machine. Checks that run on a server, such as CI, are not affected by a flag you pass locally.
On Windows, you remove the executable bit from .git/hooks/pre-commit with chmod -x. What happened in our test?
Answer: A. Nothing. The hook still ran, because the file system keeps no executable bit
\nls -l still showed -rwxr-xr-x afterwards and the hook still refused the commit. The bit matters for teammates on Linux and macOS, so record it with git update-index --chmod=+x.
pre-commit, commit-msg) with no extension. A non-zero exit stops the action.git update-index --chmod=+x for teammates elsewhere..git/hooks is not cloned. Put hooks in a tracked folder and run git config core.hooksPath .githooks once per clone.git commit --no-verify (or -n) skips pre-commit and commit-msg.A hook that cannot be skipped is not a hook. It is a server.
\nJoin the discussion on the original article.
\n", "content_text": "Hooks You Will Actually Use.\nCanonical: https://mnixblog.netlify.app/hooks-you-will-actually-use/\nStop a Bad Commit Before It Exists, and Know What a Hook Cannot Stop\nSomebody commits a .env file with a real password in it. Nobody notices until it is pushed.\nYou can write a rule for that in a README. You can mention it in review. Or you can make Git refuse the commit before it exists.\nA hook is a script that Git runs at a fixed moment, such as just before a commit is created. If the script exits with an error, Git stops.\nWe will write two hooks, make them part of the repository so a teammate gets them, and then find out exactly how to get around them, because that decides what hooks are for. This is the result, and it does not promise more than it shows:\n$ git commit -m \"Add env\"\npre-commit: refusing to commit a .env file.\nNote:\nEvery command and output in this article comes from Git 2.45.2 on Windows 11, run in Git Bash. Our stand-in for GitHub is a bare repository in a folder called hub.git.\nWhat a hook is, and where it lives\nEvery repository starts with a .git/hooks folder full of examples:\n$ ls .git/hooks\napplypatch-msg.sample\ncommit-msg.sample\nfsmonitor-watchman.sample\npost-update.sample\npre-applypatch.sample\npre-commit.sample\npre-merge-commit.sample\npre-push.sample\npre-rebase.sample\npre-receive.sample\nprepare-commit-msg.sample\npush-to-checkout.sample\nsendemail-validate.sample\nupdate.sample\nGit ignores anything ending in .sample. To turn one on, you make a file with the hook's name and no extension: pre-commit, not pre-commit.sh.\nThe two we will write:\npre-commit runs before Git asks for a commit message. It can look at what is staged. A non-zero exit stops the commit.\ncommit-msg runs after you write the message. Git gives it the path of the file that holds the message.\nA pre-commit hook that checks one thing\nA hook is just a script. This one stops a .env file from being added:\n#!/bin/sh\n# Stop a .env file from being added to a commit.\nif git diff --cached --name-only --diff-filter=AM | grep -q \"\\.env$\"; then\necho \"pre-commit: refusing to commit a .env file.\"\nexit 1\nfi\ngit diff --cached --name-only lists the files in the staging area. --diff-filter=AM keeps only those that are Added or Modified. Without that part, the hook has a bug we hit in our test: a commit that removes .env from Git also lists .env, so the hook blocked the very commit that fixed the problem.\n$ git commit -m \"Stop tracking env\"\npre-commit: refusing to commit a .env file.\nWith --diff-filter=AM, the same commit went through:\n[main 6aa0a43] Stop tracking env\n1 file changed, 1 deletion(-)\ndelete mode 100644 .env\nWindows: who runs it?\nThe first line, #!/bin/sh, is the shebang: it names the program that runs the file. Windows has no /bin/sh, and Git for Windows brings its own. Git runs hooks with that bundled shell, so the hook works no matter which terminal you start Git from. We committed from Git Bash and from PowerShell, and in both the hook ran and refused.\nThe executable bit is the other thing everybody asks about. On Linux and macOS, a hook must be executable or Git skips it. On Windows, there is no such bit on the file system. In our test, chmod -x on a hook in .git/hooks changed nothing: ls -l still showed -rwxr-xr-x, and the hook still ran. So on Windows, you do not need chmod for the hook to run for you.\nIt matters when a teammate on Linux or macOS gets your hook through the repository. That comes next.\nMake everybody get the hooks\n.git/hooks is inside .git, and .git is never part of a clone. A fresh clone has the samples and none of your hooks. We check, in a clone of the same project:\n$ git config core.hooksPath\n$ ls -A .git/hooks | grep -c sample\n14\nThe setting prints nothing, so it is not set. To share the hooks, we move them into a folder that is tracked, .githooks, and tell Git to look there:\n$ git config core.hooksPath .githooks\n$ git config core.hooksPath\n.githooks\nTwo details:\nThe setting is per clone. It lives in .git/config, which is not shared either. Every person runs that one command once, or a setup script does. In our test, a teammate's fresh clone had the .githooks folder, and a commit with a .env in it went straight through, because the setting was not there yet.\nRecord the executable bit in Git. The files are 100644 by default on Windows. Make them 100755, so a teammate on Linux or macOS gets runnable scripts:\n$ git ls-files -s .githooks/pre-commit\n100644 d9a4c991b07dbd9b526df46c0956c7b5ac972df2 0\t.githooks/pre-commit\n$ git update-index --chmod=+x .githooks/pre-commit\n$ git ls-files -s .githooks/pre-commit\n100755 d9a4c991b07dbd9b526df46c0956c7b5ac972df2 0\t.githooks/pre-commit\ngit add --chmod=+xYou need to fix a typo in one documentation page. The repository is large, and git clone is going to download every version of every file anyone ever committed.
Git has three ways to take less. They sound alike, and they cut different things.
\nWe will build a small repository with real history and clone it all three ways. That gives us a table of what each one cost on disk, and the commands that undo each one:
\ngit clone --depth 1 <url>\ngit clone --filter=blob:none --sparse <url>\ngit sparse-checkout set docs\nThis is the baseline. A normal clone of our stand-in remote:
\n$ git clone file:///C:/.../hub.git full\n$ git rev-list --count main\n29\n$ git count-objects -vH\n...\nsize-pack: 4.29 MiB\nsize-pack is the size of the packed history on disk. 4.29 MiB for a small test repository is the number to beat.
--depth 1 asks for the latest commit and nothing before it.
$ git clone --depth 1 file:///C:/.../hub.git shallow\nCloning into 'shallow'...\n$ git log --oneline\ne9769cd Change 30\n$ git rev-parse --is-shallow-repository\ntrue\n$ git count-objects -vH\n...\nsize-pack: 154.67 KiB\n154.67 KiB instead of 4.29 MiB. The cost is in that git log output: there is one commit. Git remembers where it stopped in a file, .git/shallow, which holds the id of the commit that has its parents cut off.
That is fine for a build server that only needs to compile the latest version. It is not fine when you want git blame, git log on a file, or git bisect, because the history they need is not there.
You can get more, or all of it, later:
\n$ git fetch --depth=5\n$ git log --oneline | wc -l\n5\n$ git fetch --unshallow\n$ git log --oneline | wc -l\n29\n$ git rev-parse --is-shallow-repository\nfalse\n--depth=5 grows the history to five commits. --unshallow fetches the rest and turns the repository back into a normal one.
A partial clone keeps the whole commit history but leaves out file contents, which Git calls blobs. --filter=blob:none says: no blobs yet.
$ git clone --filter=blob:none file:///C:/.../hub.git part2\nCloning into 'part2'...\n$ git rev-list --count main\n29\n$ git count-objects -vH\n...\nsize-pack: 176.46 KiB\nAll 29 commits, and 176.46 KiB on disk. A shallow clone with a single commit and this one are about the same size here, and this one still has the history.
\nWhere did the files go? Git fetches a blob when something needs it. Checking out main needed the current files, so those came with the clone. An old version of the data file is a different matter:
$ git show HEAD~20:assets/data.txt | head -c 60\n/X/SMgBvhT7YnWhpJhZn6SgfWrgGUQ6Dooe1EmkpO0fQImxUNquFAriLInCn\n$ git count-objects -vH\n...\nsize-pack: 328.08 KiB\nReading a file from 20 commits ago made Git go back to the remote and fetch that one blob. size-pack grew by about 150 KB, which is one copy of the data file. Nothing printed, so you will not see it happen.
Two things to know before you rely on this:
\nfiltering not recognized by server, ignoring and sent everything. After git config uploadpack.allowFilter true on that repository, the filter worked. GitHub supports it.$ git config --get-regexp \"remote.origin.(promisor|partialclonefilter)\"\nremote.origin.promisor true\nremote.origin.partialclonefilter blob:none\npromisor means the remote has promised to supply what is missing. Offline, with an old file you never opened, that promise cannot be kept.
A sparse checkout is about your working folder, not about what you downloaded. You tell Git to put only the folders you name on disk.
\nThe two ideas combine well. --sparse on a clone starts with only the top-level files:
$ git clone --filter=blob:none --sparse file:///C:/.../hub.git sp\n$ ls\nREADME.md\n$ git count-objects -vH\n...\nsize-pack: 24.40 KiB\n24.40 KiB. Now add the folder we work in:
\n$ git sparse-checkout set docs\n$ ls\nREADME.md\ndocs\n$ git sparse-checkout list\ndocs\nGit fetched the files in docs, and size-pack rose to 26.89 KiB. The assets and src folders are not on disk.
set replaces the list. add extends it:
$ git sparse-checkout add src\n$ ls\nREADME.md\ndocs\nsrc\nIn Git 2.45.2, set works in what Git calls cone mode: you name whole folders, and everything inside comes with them. git config core.sparseCheckoutCone printed true here.
Finally, to go back to the whole tree:
\n$ git sparse-checkout disable\n$ ls\nREADME.md\nassets\ndocs\nsrc\n$ git count-objects -vH\n...\nsize-pack: 179.69 KiB\nGit fetched the files it had skipped, and the pack grew from 26.89 KiB to 179.69 KiB.
\nAll from the same remote.
\n| Clone | Commits | size-pack | Missing |
|---|---|---|---|
| Full | 29 | 4.29 MiB | nothing |
--depth 1 | 1 | 154.67 KiB | all older history |
--filter=blob:none | 29 | 176.46 KiB | old file versions, until read |
--filter=blob:none --sparse | 29 | 24.40 KiB | files outside the sparse folders |
Git LFS is a different tool for a different problem: a few very large files, such as models or design files, that you do not want in history at all. It stores a small text pointer in Git and the file itself elsewhere.
\nWe ran it in a scratch repository, with the file type tracked before the file was added:
\n$ git lfs install --local\nUpdated Git hooks.\nGit LFS initialized.\n$ git lfs track \"*.bin\"\nTracking \"*.bin\"\n$ cat .gitattributes\n*.bin filter=lfs diff=lfs merge=lfs -text\n$ git lfs ls-files\n52ca684f48 * model.bin\n$ git cat-file -p HEAD:model.bin\nversion https://git-lfs.github.com/spec/v1\noid sha256:52ca684f4830a78b5a958d39f26e5bd276931ae753f2e3ea8476dd9f742be4ee\nsize 100000\nThe commit holds three lines of text. The 100,000 bytes live in LFS.
\nIt does not help with a file you already committed. In a second test, we added old.bin, committed it, and only then ran git lfs track \"*.bin\". git lfs ls-files printed nothing, and git cat-file -s HEAD:old.bin printed 100000, the real file. Tracking applies to new commits. History that already has the big file keeps it.
git lfs migrate, the tool for rewriting history, and GitHub's LFS storage limits were not tested here. Look those up before you rely on them.
Here is the whole tour in seven commands. The remote is https://github.com/you/big.git. Type them one at a time.
Type these commands in order, in a practice folder:
\ngit clone --depth 1 https://github.com/you/big.git. A plain git clone downloads all of the history.git rev-parse --is-shallow-repository. It prints true.git fetch --unshallow. The repository stops being shallow.git clone --filter=blob:none --sparse https://github.com/you/big.git lean. The commits come with it; the folders do not.git sparse-checkout set docs. Git fetches the files in docs.git sparse-checkout list. It prints docs.git sparse-checkout disable. Git fetches what it skipped.Try the interactive Git practice terminal on the original article.
Two things worth trying in the terminal: ask for a hint when you are stuck, and add src with git sparse-checkout add src before disabling.
Challenge: all the history, two folders
\nMake a new clone that has every commit but only docs and src on disk. Do it with a filter, not with --depth. Then prove that assets is missing from the disk and not from Git.
Expected result: git rev-list --count main prints the same number as in a full clone, ls shows README.md, docs and src, ls assets says No such file or directory, and git ls-files still lists assets/data.txt.
$ git clone --filter=blob:none --sparse file:///C:/.../hub.git lean\n$ cd lean\n$ git sparse-checkout set docs src\n$ git rev-list --count main\n29\n$ ls assets\nls: cannot access 'assets': No such file or directory\n$ git ls-files\nREADME.md\nassets/data.txt\ndocs/guide.md\nsrc/main.c\nWe ran this on a rebuilt stand-in remote, so the file names are ours. The point is the last command: the index knows assets/data.txt, the disk does not. This clone needed git config uploadpack.allowFilter true on the remote first.
You clone with --depth 1 and later run git blame on an old file. What is the problem?
--depth 1 also leaves out file contentsAnswer: A. The older commits it needs were not downloaded
\nA shallow clone has the latest commit and no history behind it. git fetch --unshallow brings the history back.
You made a partial clone with --filter=blob:none, and you read an old version of a file for the first time. What does Git do?
Answer: A. It fetches that one file version from the remote at that moment
\nIn our test, git show HEAD~20:assets/data.txt fetched one blob, and size-pack rose by about 150 KB. That is why the repository keeps the remote marked as promisor.
You track *.bin with Git LFS after old.bin was already committed. Where is old.bin stored?
Answer: A. In Git history, as before. Tracking applies to new commits
\ngit lfs ls-files printed nothing in our test, and git cat-file -s HEAD:old.bin showed the full 100000 bytes.
git clone --depth 1 takes only the latest commit. git fetch --unshallow takes the rest. With local folders, use file:/// or Git ignores --depth.--filter=blob:none takes every commit and fetches file contents when something needs them. The server has to allow it, and the repository depends on the remote afterwards.git sparse-checkout set <folders> puts only those folders on your disk. add extends the list, list shows it, disable brings back the whole tree.Next time you only need one folder, you will not wait for the rest.
\nJoin the discussion on the original article.
\n", "content_text": "Big Repositories, Shallow, Partial and Sparse.\nCanonical: https://mnixblog.netlify.app/big-repositories-shallow-partial-and-sparse/\nClone Only the Part You Need, and Know What You Gave Up\nYou need to fix a typo in one documentation page. The repository is large, and git clone is going to download every version of every file anyone ever committed.\nGit has three ways to take less. They sound alike, and they cut different things.\nA shallow clone takes fewer commits.\nA partial clone takes the commits but leaves out file contents until you need them.\nA sparse checkout takes everything, but only puts some folders on your disk.\nWe will build a small repository with real history and clone it all three ways. That gives us a table of what each one cost on disk, and the commands that undo each one:\ngit clone --depth 1You are reading checkout.js, and one line puzzles you.
return post(order, TIMEOUT_MS);\nWhy is there no retry here? You ask Git who wrote it, and git blame says Ravi, on April 20. His commit is called Reformat with 2-space indent. He did not write that line. He re-indented it.
Old code raises four questions: who wrote this line, when did this word appear, when did it vanish, and how did this function change. Git can answer all four, and it gets the right answer for that line:
\n9dcdb28d (Ada 2026-04-06 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\nOur scratch project is one file with seven commits from two made-up authors, Ada and Ravi. The output in this article comes from Git 2.45.2 on Windows 11, run in Git Bash.
\n$ git log --oneline\nd28ffe2 Round tax\n5c04fdc Reformat with 2-space indent\n9dcdb28 Stop retrying orders\nbf249d9 Give slow carriers more time\n4a90109 Add tax\n7142a9f Retry failed orders\n5c64e3c Add checkout total\nHere is the file at the end:
\nconst TIMEOUT_MS = 60000;\n\nfunction total(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n}\n\nfunction send(order) {\n return post(order, TIMEOUT_MS);\n}\n\nfunction addTax(amount) {\n return Math.round(amount * 1.2);\n}\nYour hashes may differ from the ones printed here, because the dates use your time zone, and so will the time zone offsets in the blame output. The authors, messages and dates are set on purpose.
\ngit init -b main digging && cd digging\nc() {\n git add .\n GIT_AUTHOR_NAME=\"$2\" GIT_AUTHOR_EMAIL=\"${2,,}@example.com\" \\\n GIT_COMMITTER_NAME=\"$2\" GIT_COMMITTER_EMAIL=\"${2,,}@example.com\" \\\n GIT_AUTHOR_DATE=\"$3\" GIT_COMMITTER_DATE=\"$3\" git commit -m \"$1\"\n}\ncat > checkout.js <<'EOF'\nconst TIMEOUT_MS = 30000;\n\nfunction total(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n}\nEOF\nc \"Add checkout total\" Ada 2026-02-02T10:00:00\ncat > checkout.js <<'EOF'\nconst TIMEOUT_MS = 30000;\nconst RETRY_LIMIT = 3;\n\nfunction total(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n}\n\nfunction send(order) {\n for (let i = 0; i < RETRY_LIMIT; i++) {\n if (post(order, TIMEOUT_MS)) return true;\n }\n return false;\n}\nEOF\nc \"Retry failed orders\" Ravi 2026-02-16T10:00:00\ncat >> checkout.js <<'EOF'\n\nfunction addTax(amount) {\n return amount * 1.2;\n}\nEOF\nc \"Add tax\" Ada 2026-03-02T10:00:00\nsed -i 's/TIMEOUT_MS = 30000/TIMEOUT_MS = 60000/' checkout.js\nc \"Give slow carriers more time\" Ravi 2026-03-16T10:00:00\ncat > checkout.js <<'EOF'\nconst TIMEOUT_MS = 60000;\n\nfunction total(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n}\n\nfunction send(order) {\n return post(order, TIMEOUT_MS);\n}\n\nfunction addTax(amount) {\n return amount * 1.2;\n}\nEOF\nc \"Stop retrying orders\" Ada 2026-04-06T10:00:00\nsed -i 's/^ / /' checkout.js\nc \"Reformat with 2-space indent\" Ravi 2026-04-20T10:00:00\nsed -i 's/amount \\* 1.2/Math.round(amount * 1.2)/' checkout.js\nc \"Round tax\" Ada 2026-05-04T10:00:00\ngit blame prints each line of a file next to the commit that last changed it. The whole file is too much, so -L limits it to a range. Lines 7 to 9 hold send:
$ git blame -L 7,9 checkout.js\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 7) function send(order) {\n5c04fdc4 (Ravi 2026-04-20 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 9) }\nEach row has the start of the commit hash, the author, the date and the line number, then the line itself.
\nLine 8 belongs to 5c04fdc, the reformat. Blame names the last commit that touched the line. It does not look through whitespace or style changes unless we ask.
We can also give a function name instead of numbers:
\n$ git blame -L :send checkout.js\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 7) function send(order) {\n5c04fdc4 (Ravi 2026-04-20 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 9) }\n4a901098 (Ada 2026-03-02 10:00:00 -0500 10) \nGit found send by looking for lines that look like the start of a function, so this works best on languages it recognizes well. It printed lines 7 to 10, which includes the blank line after the function.
There are two ways to get to the real author.
\nIf the commit only changed whitespace, -w tells blame to ignore whitespace when it compares lines:
$ git blame -w -L 7,9 checkout.js\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 7) function send(order) {\n9dcdb28d (Ada 2026-04-06 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 9) }\nIf the commit changed more than whitespace, such as a code formatter that rewrote quotes and wrapped lines, name the commit with --ignore-rev. Blame then acts as if that commit never happened:
$ git blame --ignore-rev 5c04fdc -L 7,9 checkout.js\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 7) function send(order) {\n9dcdb28d (Ada 2026-04-06 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\n7142a9f1 (Ravi 2026-02-16 10:00:00 -0500 9) }\nLine 8 is Ada's, from Stop retrying orders. That answers our question.
Nobody wants to retype that. Put the commit in a file, one full hash per line, and point Git at it:
\ngit log --format=%H --grep=Reformat > .git-blame-ignore-revs\ngit config blame.ignoreRevsFile .git-blame-ignore-revs\nNow plain git blame -L 7,9 checkout.js gives the answer above. The file takes full hashes. We first tried the short one, 5c04fdc, and Git answered:
fatal: invalid object name: 5c04fdc\nThe manual says the same: \"one unabbreviated object name per line.\" Lines beginning with # are ignored, so a comment saying what each commit was is a good habit.
Commit .git-blame-ignore-revs so everyone gets the list. The git config line is not shared by cloning, so each person runs it once.
Blame is about lines that exist now. For a thing that is gone, we search the changes instead. -S takes a string and lists the commits that changed how many times it appears in the code:
$ git log -S RETRY_LIMIT --oneline\n9dcdb28 Stop retrying orders\n7142a9f Retry failed orders\nThe oldest line is the commit that added RETRY_LIMIT, and the newest is the one that removed it. Add -p to see the change itself. This is the removal:
$ git log -S RETRY_LIMIT --oneline -p -1\n9dcdb28 Stop retrying orders\ndiff --git a/checkout.js b/checkout.js\nindex e14e8d1..08bde68 100644\n--- a/checkout.js\n+++ b/checkout.js\n@@ -1,15 +1,11 @@\n const TIMEOUT_MS = 60000;\n-const RETRY_LIMIT = 3;\n \n function total(items) {\n return items.reduce((sum, item) => sum + item.price, 0);\n }\n \n function send(order) {\n- for (let i = 0; i < RETRY_LIMIT; i++) {\n- if (post(order, TIMEOUT_MS)) return true;\n- }\n- return false;\n+ return post(order, TIMEOUT_MS);\n }\n \n function addTax(amount) {\nThat is the commit we wanted all along, found from a different direction.
\nTIMEOUT_MS went from 30000 to 60000 in bf249d9. Search for it with -S:
$ git log -S TIMEOUT_MS --oneline\n7142a9f Retry failed orders\n5c64e3c Add checkout total\nbf249d9 is missing. That commit changed the value, but the word TIMEOUT_MS appears the same number of times before and after, so -S does not count it. -G takes a regular expression and looks at the changed lines instead:
$ git log -G \"TIMEOUT_MS = [0-9]+\" --oneline\nbf249d9 Give slow carriers more time\n5c64e3c Add checkout total\nThere it is. Use -S when you want the commit where something was added or removed, and -G when you want any commit that touched a line matching a pattern. To search for a specific value, search for the value: git log -S\"TIMEOUT_MS = 30000\" --oneline printed bf249d9 and 5c64e3c.
git log -L follows a range of lines, or a function, through every commit that touched it. It prints each change:
$ git log -L :addTax:checkout.js\ncommit d28ffe22c9294f7a36ffc43e640fdc1ba515ffe1\nAuthor: Ada <ada@example.com>\nDate: Mon May 4 10:00:00 2026 -0400\n\n Round tax\n\ndiff --git a/checkout.js b/checkout.js\n--- a/checkout.js\n+++ b/checkout.js\n@@ -11,3 +11,3 @@\n function addTax(amount) {\n- return amount * 1.2;\n+ return Math.round(amount * 1.2);\n }\n\ncommit 5c04fdc495ac4dca9de5ef4fcaf59f427dc2fd92\nAuthor: Ravi <ravi@example.com>\nDate: Mon Apr 20 10:00:00 2026 -0400\n\n Reformat with 2-space indent\n...\nThe third commit, Add tax, is the original. The middle one is the reformat again, which -L does not skip. That is the whole history of one function, in one command.
The default git log is a lot of text. --format prints what we choose. These placeholders are the ones used most:
| Placeholder | Prints |
|---|---|
%h | Short hash |
%H | Full hash |
%an, %ae | Author name and email |
%ad | Author date, in the style --date sets |
%s | Subject line |
%b | Body of the message |
%d | Branch and tag names |
%n | A new line |
$ git log --format=\"%h %an %ad %s\" --date=short\nd28ffe2 Ada 2026-05-04 Round tax\n5c04fdc Ravi 2026-04-20 Reformat with 2-space indent\n9dcdb28 Ada 2026-04-06 Stop retrying orders\nbf249d9 Ravi 2026-03-16 Give slow carriers more time\n4a90109 Ada 2026-03-02 Add tax\n7142a9f Ravi 2026-02-16 Retry failed orders\n5c64e3c Ada 2026-02-02 Add checkout total\nFilters narrow the list before it prints:
\n| Filter | Example | Result in our history |
|---|---|---|
--since | git log --since=2026-04-01 --oneline | d28ffe2, 5c04fdc, 9dcdb28 |
--author | git log --author=Ravi --oneline | 5c04fdc, bf249d9, 7142a9f |
--grep | git log --grep=tax -i --oneline | d28ffe2, 4a90109 |
--grep searches commit messages, and -i ignores case. For comparison, -S and -G search the changes. And git log --oneline --graph --decorate draws the branches. Ours is a straight line, so it is seven stars in a column.
The whole hunt takes six commands.
\nType these commands in order, in a practice folder:
\ngit blame -L 7,9 checkout.js. Line 8 is blamed on the reformat, 5c04fdc.git blame --ignore-rev 5c04fdc -L 7,9 checkout.js. git blame -w -L 7,9 checkout.js works too, because that commit only changed whitespace. Line 8 now belongs to Ada, 9dcdb28.git log -S RETRY_LIMIT --oneline.-S misses. Try git log -G \"TIMEOUT_MS = [0-9]+\" --oneline.git log -L :addTax:checkout.js.git log --format=\"%h %an %ad %s\" --date=short.Try the interactive Git practice terminal on the original article.
Two things worth trying: type git log -S TIMEOUT_MS --oneline at step 4 and see why it is not the answer, and ask for a hint at step 2.
Challenge: one command, one line
\nThe retry loop ended with return false;, and Stop retrying orders removed it. Print who removed that line and on what date, as one line in the form Ada 2026-04-06. Use one git log command, and do not type a commit hash.
Expected result: exactly Ada 2026-04-06, and nothing else.
$ git log -S\"return false;\" -1 --format=\"%an %ad\" --date=short\nAda 2026-04-06\nWithout -1, the same command also prints Ravi's Retry failed orders, the commit that added the line.
TIMEOUT_MS changes from 30000 to 60000 in one commit. The word TIMEOUT_MS appears the same number of times before and after. Which command lists that commit?
git log -G \"TIMEOUT_MS = [0-9]+\" --onelinegit log -S TIMEOUT_MS --onelineAnswer: A. git log -G \"TIMEOUT_MS = [0-9]+\" --oneline
-S lists commits that change the number of times a string appears, and here it did not change. -G looks at the changed lines themselves.
A .git-blame-ignore-revs file lists the commits that blame should skip. How must each commit be written?
Answer: A. As its full hash, one per line
\nGit's manual asks for one unabbreviated object name per line. In our run, the seven-character hash gave fatal: invalid object name.
git blame shows a line next to a commit. Which commit is it?
Answer: A. The most recent one that changed that line
\nLine 8 was written by Ada but blamed on Ravi's reformat, because his was the last commit to change it.
\ngit blame -L 7,9 file shows who last changed those lines. -L :send takes a function name.git blame -w ignores whitespace changes. --ignore-rev <commit> ignores a whole commit..git-blame-ignore-revs lists full hashes, and git config blame.ignoreRevsFile points Git at it. The config is per clone.git log -S text finds commits that change how many times the text appears. -G regex finds commits whose changed lines match.git log -L :function:file shows every change to a function.--format, --date, --since, --author and --grep shape what git log prints.Blame, the pickaxe and -L tell us which commit to look at. The commit message and the diff tell us why, and git show 9dcdb28 prints both.
Join the discussion on the original article.
\n", "content_text": "Dig Through History.\nCanonical: https://mnixblog.netlify.app/dig-through-history/\nBlame, the Pickaxe, and the Reformat That Hid the Author\nYou are reading checkout.js, and one line puzzles you.\nreturn post(order, TIMEOUT_MS);\nWhy is there no retry here? You ask Git who wrote it, and git blame says Ravi, on April 20. His commit is called Reformat with 2-space indent. He did not write that line. He re-indented it.\nOld code raises four questions: who wrote this line, when did this word appear, when did it vanish, and how did this function change. Git can answer all four, and it gets the right answer for that line:\n9dcdb28d (Ada 2026-04-06 10:00:00 -0400 8) return post(order, TIMEOUT_MS);\nA history to dig through\nOur scratch project is one file with seven commits from two made-up authors, Ada and Ravi. The output in this article comes from Git 2.45.2 on Windows 11, run in Git Bash.\n$ git log --oneline\nd28ffe2 Round tax\n5c04fdc Reformat with 2-space indent\n9dcdb28 Stop retrying orders\nbf249d9 Give slow carriers more time\n4a90109 Add tax\n7142a9f Retry failed orders\n5c64e3c Add checkout total\nHere is the file at the end:\nconst TIMEOUT_MS = 60000;\nfunction total(items) {\nreturn items.reduce((sum, item) => sum + item.price, 0);\n}\nfunction send(order) {\nreturn post(order, TIMEOUT_MS);\n}\nfunction addTax(amount) {\nreturn Math.round(amount * 1.2);\n}\nA check that passed at v1.0 fails today. In between there are thirteen commits.
$ sh check.sh; echo $?\n1\nThe hashes in this article, such as e2b28b4, come from our own run. Yours will differ, so match commits by their messages.
You could read thirteen diffs. You could check out each commit and run the check. Or you can let Git do the searching, and tell it only whether a commit is good or bad.
\ngit bisect finds the commit that broke the check. One command answers the question without any help from us:
$ git bisect run sh check.sh\n...\ne2b28b48490fa9fca263b1139911de5315b6778c is the first bad commit\nOur scratch project is a single script, bill.sh, which multiplies a quantity by a price. check.sh tests it:
#!/bin/sh\n# exits 0 when 3 items at 4 each total 12\n[ \"$(sh bill.sh 3 4)\" = \"12\" ]\nThe exit code is the whole result. 0 means the check passed, anything else means it failed. That is the contract bisect uses, so keep it in mind.
The history has sixteen commits, and v1.0 is a tag on the third:
$ git log --oneline\naa1dcd3 Invite contributions\n0f1c2ac Add plums\n9a951ee Note whole-number prices\ne1eb7c8 Explain item list\n977c5b3 Add cherries\ne2b28b4 Add loyalty discount\n78bad62 Mention check.sh\n189fe51 Comment the formula\n97330b4 Add bananas\n1bf0dc7 Add license\n500813b Ignore log files\n32b8a71 Add pears\nab70081 Add item list\nf81a834 Document usage\nfa1d2e4 Add README\n60d1b2a Add bill script\nMost of these commits touch a README or a list of fruit. One of them changed the arithmetic. The output in this article comes from Git 2.45.2 on Windows 11, run in Git Bash.
\nYour hashes will differ from the ones printed here. The history, the tag and the results will match.
\ngit init -b main bill && cd bill\nc() { git add . && git commit -m \"$1\"; }\nprintf '#!/bin/sh\\necho $(( $1 * $2 ))\\n' > bill.sh\nprintf '#!/bin/sh\\n# exits 0 when 3 items at 4 each total 12\\n[ \"$(sh bill.sh 3 4)\" = \"12\" ]\\n' > check.sh\nc \"Add bill script\"\necho \"# Bill\" > README.md; c \"Add README\"\necho \"Usage: sh bill.sh QUANTITY PRICE\" >> README.md; c \"Document usage\"\ngit tag v1.0\necho \"apple 4\" > items.txt; c \"Add item list\"\necho \"pear 5\" >> items.txt; c \"Add pears\"\necho \"*.log\" > .gitignore; c \"Ignore log files\"\necho \"MIT\" > LICENSE; c \"Add license\"\necho \"banana 2\" >> items.txt; c \"Add bananas\"\nprintf '#!/bin/sh\\n# total = quantity * price\\necho $(( $1 * $2 ))\\n' > bill.sh; c \"Comment the formula\"\necho \"Run check.sh to test.\" >> README.md; c \"Mention check.sh\"\nprintf '#!/bin/sh\\n# total = quantity * price, less a loyalty discount\\necho $(( $1 * $2 - 1 ))\\n' > bill.sh; c \"Add loyalty discount\"\necho \"cherry 9\" >> items.txt; c \"Add cherries\"\necho \"Items live in items.txt.\" >> README.md; c \"Explain item list\"\nprintf '#!/bin/sh\\n# total = quantity * price, less a loyalty discount\\n# prices are whole numbers\\necho $(( $1 * $2 - 1 ))\\n' > bill.sh; c \"Note whole-number prices\"\necho \"plum 3\" >> items.txt; c \"Add plums\"\necho \"Contributions welcome.\" >> README.md; c \"Invite contributions\"\nBisect is a binary search. We tell Git one commit that is bad and one that is good. Git checks out the commit in the middle, and we say whether it is good or bad. Whatever we answer throws away half of the commits that are left.
\ngood ● ● ● ● ● ● ● ● ● ● ● ● ● ● bad\n test here\nThirteen commits take about four tests. Sixty-four take about six, and a thousand take about ten. Every extra test doubles the number of commits we can cover.
\nWe start the session, then tell Git which end is which. The commit we are standing on is bad, and the v1.0 tag was good:
$ git bisect start\nstatus: waiting for both good and bad commits\n$ git bisect bad\nstatus: waiting for good commit(s), bad commit known\n$ git bisect good v1.0\nBisecting: 6 revisions left to test after this (roughly 3 steps)\n[189fe51b563dc16a0f96744518ba87072c7a5e36] Comment the formula\nGit has now checked out 189fe51, in the middle. Our working folder holds that commit. We run the check:
$ sh check.sh; echo $?\n0\n$ git bisect good\nBisecting: 3 revisions left to test after this (roughly 2 steps)\n[977c5b326b651d1920eaeb0f82eaec1458d313c1] Add cherries\nIt passed, so everything up to and including 189fe51 is good. Git jumped to the middle of what is left.
$ sh check.sh; echo $?\n1\n$ git bisect bad\nBisecting: 0 revisions left to test after this (roughly 1 step)\n[e2b28b48490fa9fca263b1139911de5315b6778c] Add loyalty discount\n$ sh check.sh; echo $?\n1\n$ git bisect bad\nBisecting: 0 revisions left to test after this (roughly 0 steps)\n[78bad623c1471205a79ced65f082805a7e706ddd] Mention check.sh\nGit's estimates say \"roughly\", and ours was off by one: it predicted three steps and we answered four times. The last commit it asks about is the one just before the suspect.
\n$ sh check.sh; echo $?\n0\n$ git bisect good\ne2b28b48490fa9fca263b1139911de5315b6778c is the first bad commit\ncommit e2b28b48490fa9fca263b1139911de5315b6778c\nAuthor: Test User <test@example.com>\nDate: Mon Oct 26 19:23:19 2026 -0400\n\n Add loyalty discount\n\n bill.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\nFour tests, and the answer is Add loyalty discount. Here is what it did:
$ git show e2b28b4\n...\n-# total = quantity * price\n-echo $(( $1 * $2 ))\n+# total = quantity * price, less a loyalty discount\n+echo $(( $1 * $2 - 1 ))\nA discount of one unit, subtracted from every total.
\nWhile bisecting, we are not on a branch:
\n$ git status\nHEAD detached at 189fe51\nYou are currently bisecting, started from branch 'main'.\n (use \"git bisect reset\" to get back to the original branch)\nThat is expected. When we are done, whether we found the answer or gave up, we leave:
\n$ git bisect reset\nPrevious HEAD position was 78bad62 Mention check.sh\nSwitched to branch 'main'\nStart with a clean working folder. Bisect checks out other commits, so uncommitted work is in its way. Stash it first.
\nWe answered good or bad four times by running the same command and reading the exit code. That is a job for a script. git bisect run does exactly that loop:
$ git bisect start HEAD v1.0\nBisecting: 6 revisions left to test after this (roughly 3 steps)\n[189fe51b563dc16a0f96744518ba87072c7a5e36] Comment the formula\n$ git bisect run sh check.sh\nrunning 'sh' 'check.sh'\nBisecting: 3 revisions left to test after this (roughly 2 steps)\n[977c5b326b651d1920eaeb0f82eaec1458d313c1] Add cherries\nrunning 'sh' 'check.sh'\nBisecting: 0 revisions left to test after this (roughly 1 step)\n[e2b28b48490fa9fca263b1139911de5315b6778c] Add loyalty discount\nrunning 'sh' 'check.sh'\nBisecting: 0 revisions left to test after this (roughly 0 steps)\n[78bad623c1471205a79ced65f082805a7e706ddd] Mention check.sh\nrunning 'sh' 'check.sh'\ne2b28b48490fa9fca263b1139911de5315b6778c is the first bad commit\n...\nbisect found first bad commit\ngit bisect start HEAD v1.0 is the shorthand for the first three commands: bad first, then good. Same commit as by hand, and we did not type an answer.
Git reads the exit code of the command after run. The manual defines it:
| Exit code | Meaning |
|---|---|
0 | The commit is good |
1 to 127, except 125 | The commit is bad |
125 | The commit cannot be tested, so skip it |
Anything else, such as 255 | Stop the whole bisect |
That means a script that cannot start looks like a bad commit. Exit code 127 is the shell's \"command not found\", and bisect counts it as bad. To see it, we ran a script name that does not exist:
$ git bisect run sh nothere.sh\nrunning 'sh' 'nothere.sh'\nsh: nothere.sh: No such file or directory\n[f81a83459eb425d69352d2232cb15b127a31236d] Document usage\nrunning 'sh' 'nothere.sh'\nsh: nothere.sh: No such file or directory\nerror: bogus exit code 127 for good revision\nGit moved down to v1.0, which we said was good, got a failure there too, and stopped. This is what you would see if check.sh was added to the repository after v1.0: older commits do not have it. Keep a test script outside the repository, or untracked, so it survives every checkout.
When a commit fails for a reason that is not our bug, such as a build that does not compile, the script should say so with 125:
make || exit 125\nsh check.sh\nGit skips that commit and picks another. By hand, git bisect skip does the same.
And we reset when finished:
\n$ git bisect reset\nPrevious HEAD position was 78bad62 Mention check.sh\nSwitched to branch 'main'\nBisect finds the first commit where the check changed from passing to failing. It does not explain why that change broke the check. Reading the diff is still our job. And it trusts our answers. If the check is flaky, or we mark one commit wrong, the search narrows on the wrong half and ends with a confident wrong commit. We have not tested what Git does on branches with many merges, so check that case on your own history before relying on it.
\nHere is the same hunt as ten commands. Match each commit by its message, not its hash.
\nType these commands in order, in a practice folder:
\ngit bisect start.git bisect bad.v1.0 tag as good. Try git bisect good v1.0. Git checks out the commit in the middle, Comment the formula.sh check.sh printed 0 at Comment the formula. Tell Git: git bisect good.Add cherries it printed 1. Tell Git: git bisect bad.Add loyalty discount it printed 1. Tell Git: git bisect bad.Mention check.sh it printed 0. Tell Git: git bisect good. Git names the first bad commit, Add loyalty discount.git bisect reset.git bisect start HEAD v1.0.git bisect run sh check.sh.Try the interactive Git practice terminal on the original article.
Two things worth trying: answer bad at step 4 and read what the terminal says about the exit code, and finish the lesson and count how many times the script ran.
Challenge: ask a different question
\ncheck.sh tests arithmetic, so it is no use here. In the same project, find the first commit after v1.0 where items.txt contains the word cherry. Use git bisect run with one inline command, and no script file.
Expected result: Git prints ... is the first bad commit, and the commit is Add cherries. Run git bisect reset afterwards.
$ git bisect start HEAD v1.0\n$ git bisect run sh -c '! grep -q cherry items.txt'\n...\nAdd cherries\n...\nbisect found first bad commit\nAt v1.0 there is no items.txt, so grep fails and ! turns that into a pass. That is the right answer for a commit that has no cherries. The quotes are for Git Bash.
A script run by git bisect run exits with code 125. What does Git do with that commit?
Answer: A. It skips the commit, because it cannot be tested
\n125 is the code reserved for \"cannot be tested\". The commit is skipped, and Git picks another to try.
Roughly how many commits must bisect test to find the first bad one among 64 commits?
\nAnswer: A. About 6
\nEvery test halves the commits that are left. 64 halves to 32, 16, 8, 4, 2, 1, which is six tests.
\nWhat does git bisect reset do?
Answer: A. Ends the session and checks out the branch you started from
\nreset only ends the search and takes you back. In our run it printed Switched to branch 'main'. It does not change any commit.
git bisect is a binary search over history. We name one good and one bad commit, and Git checks out the middle.git bisect start, git bisect bad, git bisect good v1.0, then good or bad after each check.git bisect start HEAD v1.0 followed by git bisect run sh check.sh does the whole search from one script.0 good, 1 to 127 bad except 125, which skips the commit.git bisect reset always ends the session and returns to the branch.Join the discussion on the original article.
\n", "content_text": "Find the Commit That Broke It.\nCanonical: https://mnixblog.netlify.app/find-the-commit-that-broke-it/\ngit bisect, by Hand and by Script\nA check that passed at v1.0 fails today. In between there are thirteen commits.\n$ sh check.sh; echo $?\n1\nThe hashes in this article, such as e2b28b4, come from our own run. Yours will differ, so match commits by their messages.\nYou could read thirteen diffs. You could check out each commit and run the check. Or you can let Git do the searching, and tell it only whether a commit is good or bad.\ngit bisect finds the commit that broke the check. One command answers the question without any help from us:\n$ git bisect run sh check.sh\n...\ne2b28b48490fa9fca263b1139911de5315b6778c is the first bad commit\nA project with one broken commit\nOur scratch project is a single script, bill.sh, which multiplies a quantity by a price. check.sh tests it:\n#!/bin/sh\n# exits 0 when 3 items at 4 each total 12\n[ \"$(sh bill.sh 3 4)\" = \"12\" ]\nThe exit code is the whole result. 0 means the check passed, anything else means it failed. That is the contract bisect uses, so keep it in mind.\nThe history has sixteen commits, and v1.0 is a tag on the third:\n$ git log --oneline\naa1dcd3 Invite contributions\n0f1c2ac Add plums\n9a951ee Note whole-number prices\ne1eb7c8 Explain item list\n977c5b3 Add cherries\ne2b28b4 Add loyalty discount\n78bad62 Mention check.sh\n189fe51 Comment the formula\n97330b4 Add bananas\n1bf0dc7 Add license\n500813b Ignore log files\n32b8a71 Add pears\nab70081 Add item list\nf81a834 Document usage\nfa1d2e4 Add README\n60d1b2a Add bill script\nMost of these commits touch a README or a list of fruit. One of them changed the arithmetic. The output in this article comes from Git 2.45.2 on Windows 11, run in Git Bash.\nYour branch is ready for review. Then you run git log --oneline main.. and read it out loud:
$ git log --oneline main..\n96eed00 Debug output\nda9c2a6 wip\n872747b Fix typo in search box\n736ca7c Add search results\n038a3d4 wip\nb4b3152 Add search box\nThe main.. part means \"the commits on this branch that are not on main\".
The hashes on the left (96eed00 and friends) differ for every reader, because a hash comes from the commit's content, author and time. Run git log --oneline main.. in your own repository and use the hashes it prints wherever we type one.
Two commits called wip. One that fixes a typo you made three commits earlier. One that prints debug output to the console. A reviewer has to read all of it.
In this article, we are going to rewrite that list before anyone else sees it. We will use git rebase -i, which stands for interactive rebase, and by the end the same command will print this:
87dadb7 Add search results\n41d82a3 Style the search box\n23b3420 Add a search box\nThree commits, each with a message that says what it does. We will also look at the ways out when a rebase goes wrong, and the one case where we should not start it at all.
\nThree small commands come up here. git commit --amend rewrites the last commit, git cherry-pick copies one commit onto another branch, and git stash parks uncommitted changes. That is all you need from them. Advanced Git Features teaches each one properly, but you can skip it for now.
Everything below runs in a throwaway folder. The commands and the output in this article come from Git 2.45.2 on Windows 11, run in Git Bash.
\nYour hashes will differ from the ones printed here. Everything else will match.
\ngit init -b main notes && cd notes\necho \"<h1>Home</h1>\" > index.html\ngit add . && git commit -m \"Add home page\"\necho \"body { margin: 0; }\" > style.css\ngit add . && git commit -m \"Add base styles\"\ngit switch -c feature/search\necho '<input name=\"q\" placeholder=\"Seach\">' > search.html\ngit add . && git commit -m \"Add search box\"\necho \".search { width: 20em; }\" >> style.css\ngit add . && git commit -m \"wip\"\necho \"<ul id=results></ul>\" > results.html\ngit add . && git commit -m \"Add search results\"\necho '<input name=\"q\" placeholder=\"Search\">' > search.html\ngit add . && git commit -m \"Fix typo in search box\"\necho \".search:focus { outline: 2px solid; }\" >> style.css\ngit add . && git commit -m \"wip\"\necho \"<script>console.log('results')</script>\" >> results.html\ngit add . && git commit -m \"Debug output\"\nThink of a messy first draft. Before you hand it to anyone, you reorder the pages, merge two of them and tear one out. Rebase does that to commits. In Git's words, rebase means \"take these commits and replay them on a different base.\" Interactive means \"show me the list first, so I can change it.\"
\ngit rebase -i main\nGit opens your editor with one line per commit on the branch. This is the top of the file:
\npick b4b3152 Add search box\npick 038a3d4 wip\npick 736ca7c Add search results\npick 872747b Fix typo in search box\npick da9c2a6 wip\npick 96eed00 Debug output\nBelow the list, Git prints its own cheat sheet in comment lines.
\nIf the editor that opens is Vim, you only need four moves. Press i to start typing, and Esc when you are done. To move a whole line, put the cursor on it, press dd to cut it, move to the line above where it should go, and press p to paste it below. Then type :wq and press Enter to save and close.
To use another editor instead, set it once. For VS Code that is git config --global core.editor \"code --wait\". The --wait makes Git hold on until you close the tab.
Notice the order. git log shows the newest commit first. This list shows the oldest first, and Git replays it from the top down.
Each line starts with a command. These five do nearly everything:
\n| Command | What it does |
|---|---|
pick | Keep the commit as it is |
reword | Keep the commit, and open the editor to change its message |
squash | Meld the commit into the one above it, and combine the two messages |
fixup | Meld the commit into the one above it, and throw its message away |
drop | Remove the commit |
You can also reorder lines. If you delete every line, Git aborts the rebase.
\nHere is what we want:
\nwip becomes Style the search box, and absorbs the second wip.Add search results stays.Debug output goes.Move the lines, change the words at the start of each, and save. Use the hashes from your own list:
\nreword b4b3152 Add search box\nfixup 872747b Fix typo in search box\nreword 038a3d4 wip\nfixup da9c2a6 wip\npick 736ca7c Add search results\ndrop 96eed00 Debug output\nDropping a commit can conflict with the ones after it. If we had dropped Add search results instead, Debug output would have failed to apply, because it edits results.html, which that commit creates. Git stops with CONFLICT (modify/delete). If that happens, run git rebase --abort, and the branch is back as it was.
Git works down the list. At each reword, it stops and opens the editor for the message. We typed Add a search box, then Style the search box. When the last line is done:
Successfully rebased and updated refs/heads/feature/search.\n$ git log --oneline main..\n87dadb7 Add search results\n41d82a3 Style the search box\n23b3420 Add a search box\nEvery hash changed, including Add search results, which we did not touch. A commit's hash depends on its parent, so replaying on a new parent makes a new commit. That is why rewriting history has consequences, and we will come back to it.
We used fixup, which keeps the message from the top commit only. squash keeps both and opens the editor so we can combine them. In another scratch branch, we changed Add search results to squash:
pick 1631805 Add search box\nsquash 1a2b9b0 Add search results\npick f557164 Style the search box\nThe editor opens with this at the top:
\n# This is a combination of 2 commits.\n# This is the 1st commit message:\n\nAdd search box\n\n# This is the commit message #2:\n\nAdd search results\nEdit the text above the # lines into the one message you want, and save. Use fixup when the second commit is a correction and squash when its message is worth reading.
The reviewer comes back: the placeholder text should say \"Search notes\". That belongs in Add a search box, which is two commits down. We could amend, but only the latest commit is easy to amend. Instead, with the hash of Add a search box from your own git log --oneline main..:
$ echo '<input name=\"q\" placeholder=\"Search notes\">' > search.html\n$ git add search.html\n$ git commit --fixup 23b3420\n[feature/search 9c64964] fixup! Add a search box\n 1 file changed, 1 insertion(+), 1 deletion(-)\n--fixup takes the hash of the commit the change belongs to, and writes a commit called fixup! Add a search box. Now we ask rebase to put it in the right place:
git rebase -i --autosquash main\nGit writes the todo for us. The first lines:
\npick 23b3420 Add a search box\nfixup 9c64964 fixup! Add a search box\npick 41d82a3 Style the search box\npick 87dadb7 Add search results\nSave without changing anything, and the fix is inside the first commit. We typed no fixup ourselves.
To make --autosquash the default for git rebase -i, set it once:
git config rebase.autoSquash true\nAdd --global to set it for every repository. We ran it without --global in a scratch repository, and plain git rebase -i main produced the same todo.
If this is your first rebase, skip ahead to \"When the rebase goes wrong\". This section is for when one branch sits on top of another.
\nSometimes one branch sits on top of another. Here search-history is built on search, and then main moves on:
* 93e0fe4 (main) Add footer\n| * 7038177 (HEAD -> search-history) Style recent searches\n| * f634c73 Add recent searches\n| * e5efeec (search) Add search results\n| * 4f084fb Add search box\n|/\n* 215815f Add home page\nRebase search-history onto main and look at the branch called search:
* 09fb68a (HEAD -> search-history) Style recent searches\n* 8281a38 Add recent searches\n* 6e5c6a3 Add search results\n* 397f169 Add search box\n* 93e0fe4 (main) Add footer\n| * e5efeec (search) Add search results\n| * 4f084fb Add search box\n|/\n* 215815f Add home page\nsearch stayed behind. Its commits were replayed, but the label did not follow them. We put everything back with git reset --hard ORIG_HEAD, and ran it again with one flag:
git rebase --update-refs main\nSuccessfully rebased and updated refs/heads/search-history.\nUpdated the following refs with --update-refs:\n\trefs/heads/search\n* 7e4602a (HEAD -> search-history) Style recent searches\n* e5caf30 Add recent searches\n* 682f791 (search) Add search results\n* 30bb4f9 Add search box\n* 93e0fe4 (main) Add footer\n* 215815f Add home page\nBoth branch names moved. --update-refs is available from Git 2.38, and git config rebase.updateRefs true turns it on for every rebase. Git will not move a branch that is checked out in another worktree.
Reordering commits is the easiest way to cause a conflict. Suppose we move Debug output to the top of the todo. That commit edits results.html, which does not exist yet at that point in the replay:
$ git rebase -i main\nCONFLICT (modify/delete): results.html deleted in HEAD and modified in 96eed00 (Debug output). Version 96eed00 (Debug output) of results.html left in tree.\nRebasing (1/6)error: could not apply 96eed00... Debug output\nhint: Resolve all conflicts manually, mark them as resolved with\nhint: \"git add/rm <conflicted_files>\", then run \"git rebase --continue\".\nhint: You can instead skip this commit: run \"git rebase --skip\".\nhint: To abort and get back to the state before \"git rebase\", run \"git rebase --abort\".\n$ git status --short\nDU results.html\nGit stopped in the middle. We have three choices:
\ngit add it, and run git rebase --continue.git rebase --skip drops the commit it could not apply.git rebase --abort puts everything back.--abort is the one to remember. After it, the branch is exactly as it was before we typed git rebase:
$ git rebase --abort\n$ git status\nOn branch feature/search\nnothing to commit, working tree clean\n$ git log --oneline main..\n96eed00 Debug output\nda9c2a6 wip\n872747b Fix typo in search box\n736ca7c Add search results\n038a3d4 wip\nb4b3152 Add search box\nMaybe the rebase succeeded and the result is wrong. We dropped a commit that we needed. Git saves where the branch pointed before a rebase in ORIG_HEAD:
$ git reset --hard ORIG_HEAD\nHEAD is now at 96eed00 Debug output\nAll six original commits are back. Other commands can overwrite ORIG_HEAD, so do this straight away. If you wait, the reflog still has the old position.
If you have never pushed a branch to a shared remote, you can skip the force-push part for now. The first paragraph is the one to keep.
\nRebasing replaces commits with new ones. That is fine for commits only you have. It is a problem for commits somebody else already has.
\nWe pushed our branch, then reworded the last commit and pushed again:
\n$ git push\n ! [rejected] feature/search -> feature/search (non-fast-forward)\nerror: failed to push some refs to 'origin'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. If you want to integrate the remote changes,\nhint: use 'git pull' before pushing again.\nThe remote still has the old commit and we have a new one, so Git sees two histories that diverged. To replace the remote branch we have to force it. --force-with-lease is the careful way to do that:
$ git push --force-with-lease\n + eb42e06...9adb2e6 feature/search -> feature/search (forced update)\nIt overwrites the remote branch only if the remote still points where we last saw it. To test that, a second clone pushed a commit to feature/search. Then we rewrote our commit again and pushed:
$ git push --force-with-lease\n ! [rejected] feature/search -> feature/search (stale info)\nGit refused. Plain git push --force in the same situation did not:
$ git push --force\n + 2c44758...7d8835e feature/search -> feature/search (forced update)\nThat commit from the second clone is no longer on the remote branch.
\nSo the rule has two parts:
\nRewriting a branch that is already in a pull request is common, and --force-with-lease is how it is done safely. The risk is a teammate who started work on top of those commits. Their copy still has the old ones.
The whole workflow takes six commands. The terminal knows the scene for each step.
\nType these commands in order, in a practice folder:
\ngit log --oneline main... It shows six commits, including two called wip.git commit --fixup b4b3152. Git names the new commit fixup! Add search box.git rebase -i --autosquash main. Without --autosquash, the fixup stays at the bottom of the list.git rebase --update-refs main.git rebase --abort. The branch goes back to how it was before the rebase.git reset --hard ORIG_HEAD. ORIG_HEAD is where the branch pointed before the rebase.Try the interactive Git practice terminal on the original article.
Two things worth trying: type git rebase -i main at step 3 and read what the terminal says is missing, and run git reflog at step 6.
Challenge: fold it in the right place
\nTake the six-commit branch and rewrite it so that git log --oneline main.. prints exactly two commits, Add search results on top of Add search box. Both wip commits and the typo fix must end up inside Add search box, and Debug output must be gone.
Expected result: git show HEAD~:search.html prints <input name=\"q\" placeholder=\"Search\">, spelled correctly.
The two-line log is the easy part. The typo fix is the trap: if it stays where it was, it folds into Add search results, and the log looks right while the first commit still says Seach.
Move the lines so every commit that belongs in Add search box sits directly under it:
pick b4b3152 Add search box\nfixup 038a3d4 wip\nfixup 872747b Fix typo in search box\nfixup da9c2a6 wip\npick 736ca7c Add search results\ndrop 96eed00 Debug output\nWe ran this one, and style.css kept both wip rules while results.html lost its <script> line.
In the todo list that git rebase -i opens, which commit runs first?
Answer: A. The one on the top line, which is the oldest
\nThe list is the reverse of git log. Git replays it from the top down, so the oldest commit is first.
You mark a commit fixup in the todo list. What happens to its message?
Answer: A. It is discarded and the commit above keeps its message
\nfixup throws the message away. squash is the one that keeps both and opens the editor.
In our scratch repository, why did Git stop when Debug output was moved to the top of the list?
Debug output cannot be reorderedrewordAnswer: A. It edits results.html, which no earlier commit had created yet
\nThe conflict was modify/delete: results.html is created by Add search results, which now came later. Moving a commit above the one it depends on is a common cause of conflicts.
git rebase -i main lists the branch's commits, oldest first, and replays them from the top down.pick, reword, squash, fixup and drop change what each commit becomes. Lines can be reordered.git commit --fixup <id> followed by git rebase -i --autosquash main puts a late fix inside the commit it belongs to.git rebase --update-refs main (Git 2.38 or newer) moves the branches stacked below along with it.git rebase --abort returns to the state before the rebase. git reset --hard ORIG_HEAD does the same after one has finished.--force-with-lease, never plain --force, and tell anyone building on the branch.Our branch is tidy and ready for review. Sooner or later, a commit that looked fine in review turns out to have broken something, and nobody remembers which one. Next, in Find the Commit That Broke It, we find it without reading the whole history.
\nJoin the discussion on the original article.
\n", "content_text": "Interactive Rebase, Done Properly.\nCanonical: https://mnixblog.netlify.app/interactive-rebase-done-properly/\nReword, Squash, Fixup, Drop, and the Ways Back Out\nYour branch is ready for review. Then you run git log --oneline main.. and read it out loud:\n$ git log --oneline main..\n96eed00 Debug output\nda9c2a6 wip\n872747b Fix typo in search box\n736ca7c Add search results\n038a3d4 wip\nb4b3152 Add search box\nThe main.. part means \"the commits on this branch that are not on main\".\nThe hashes on the left (96eed00 and friends) differ for every reader, because a hash comes from the commit's content, author and time. Run git log --oneline main.. in your own repository and use the hashes it prints wherever we type one.\nTwo commits called wip. One that fixes a typo you made three commits earlier. One that prints debug output to the console. A reviewer has to read all of it.\nIn this article, we are going to rewrite that list before anyone else sees it. We will use git rebase -i, which stands for interactive rebase, and by the end the same command will print this:\n87dadb7 Add search results\n41d82a3 Style the search box\n23b3420 Add a search box\nThree commits, each with a message that says what it does. We will also look at the ways out when a rebase goes wrong, and the one case where we should not start it at all.\nThree small commands come up here. git commit --amend rewrites the last commit, git cherry-pick copies one commit onto another branch, and git stash parks uncommitted changes. That is all you need from them. Advanced Git Features (https://mnixblog.netlify.app/advanced-git-features/) teaches each one properly, but you can skip it for now.\nThe scratch repository\nEverything below runs in a throwaway folder. The commands and the output in this article come from Git 2.45.2 on Windows 11, run in Git Bash.\n\nVue offers excellent support for Web Components with its built-in directive syntax.\nThis demo shows how properties and events work.\n
\nVue's declarative syntax makes Web Component integration straightforward
\nWhen needed, Vue can access Web Components directly with $refs
\nA real Svelte component driving a Web Component with bind:this, a store, and its events
\nCompare calling the Web Component's own method with updating a Svelte store
\nThis demo shows how lazy-loading can improve performance by loading components only when needed.
\nAll components are loaded immediately, which can slow down initial page load.
\nComponents are loaded on-click, improving initial page load but requiring user action.
\nComponents load automatically when scrolled into view - the best of both worlds.
\nScroll down to see components load as they enter the viewport:
\n// Only load when the user takes an action\nconst loadComponent = async () => {\nconst startTime = performance.now();\n// Dynamic import of the component module\nconst { MyComponent } = await import('./my-component.js');\n// Register the component only when needed\ncustomElements.define('my-component', MyComponent);\n// Create and add the component to the page\nconst component = document.createElement('my-component');\ndocument.querySelector('#container').appendChild(component);\nconst loadTime = performance.now() - startTime;\nconsole.log(`Component loaded in ${loadTime}ms`);\n}// Create observer for viewport detection\nconst observer = new IntersectionObserver((entries) => {\nentries.forEach(entry => {\nif (entry.isIntersecting) {\nconst placeholder = entry.target;\n// Load component when placeholder is visible\nimport('./lazy-component.js')\n.then(module => {\n// Replace placeholder with actual component\nconst component = document.createElement('lazy-component');\nplaceholder.parentNode.replaceChild(component, placeholder);\n// Stop observing this element\nobserver.unobserve(placeholder);\n});\n}\n});\n}, { rootMargin: '100px' });\n// Start observing placeholders\ndocument.querySelectorAll('.component-placeholder')\n.forEach(el => observer.observe(el));Compare optimized vs. unoptimized rendering approaches in Web Components
\nWatch the difference between optimized and unoptimized component updates when handling frequent state changes.
\nInstead of updating the DOM multiple times, batch changes into a single update using DocumentFragment.
\n// Unoptimized: Multiple separate DOM operations\nupdateItems(items) {\n// Clear existing items\nthis.listElement.innerHTML = '';\n// Add each item individually (multiple DOM operations)\nitems.forEach(item => {\nconst li = document.createElement('li');\nli.textContent = item.text;\nthis.listElement.appendChild(li);\n});\n}// Optimized: Single DOM operation with DocumentFragment\nupdateItems(items) {\n// Create fragment (in-memory container)\nconst fragment = document.createDocumentFragment();\n// Build complete structure in memory\nitems.forEach(item => {\nconst li = document.createElement('li');\nli.textContent = item.text;\nfragment.appendChild(li);\n});\n// Single DOM operation\nthis.listElement.innerHTML = '';\nthis.listElement.appendChild(fragment);\n}Schedule visual updates to align with the browser's render cycle for smoother animations.
\n// Unoptimized: Direct style changes\nupdatePosition(x, y) {\n// This might cause layout thrashing if called frequently\nthis.element.style.transform = `translate(${x}px, ${y}px)`;\n}// Optimized: RAF for smooth visual updates\nupdatePosition(x, y) {\n// Store the values to update\nthis._pendingX = x;\nthis._pendingY = y;\n// Only schedule update if none is pending\nif (!this._updateScheduled) {\nthis._updateScheduled = true;\nrequestAnimationFrame(() => {\n// Apply all pending updates at once\nthis.element.style.transform =\n`translate(${this._pendingX}px, ${this._pendingY}px)`;\nthis._updateScheduled = false;\n});\n}\n}Limit the frequency of updates when properties change rapidly.
\n// Unoptimized: Update on every property change\nset value(newValue) {\nthis._value = newValue;\nthis.render(); // May be called too frequently\n}// Optimized: Debounced updates\nconstructor() {\nsuper();\nthis._value = 0;\nthis._debounceTimeout = null;\n}\nset value(newValue) {\nthis._value = newValue;\n// Clear previous timeout\nclearTimeout(this._debounceTimeout);\n// Schedule a new update with a delay\nthis._debounceTimeout = setTimeout(() => {\nthis.render();\n}, 16); // Roughly one frame at 60fps\n}This content is slotted from light DOM
\n