Autarchy of the Private Cave

Under a few assumptions (most importantly – you do not have any non-merged branches,), it is very easy to throw away git repository commits older than an arbitrarily-chosen commit.

Here’s a sample script (call it e.g. git-truncate and put into your ~/bin or whichever location you have in PATH).


#!/bin/bash
git checkout --orphan temp $1
git commit -m "Truncated history"
git rebase --onto temp $1 master
git branch -D temp
# The following 2 commands are optional - they keep your git repo in good shape.
git prune --progress # delete all the objects w/o references
git gc --aggressive # aggressively collect garbage; may take a lot of time on large repos


Invocation: cd to your repository, then git-truncate refspec, where refspec is either a commit’s SHA1 hash-id, or a tag.

Expected result: a git repository starting with “Truncated history” initial commit, and continuing to the tip of the branch you were on when calling the script.

If you truncate repositories often, then consider adding an optional 2nd argument (truncate-commit message) and also some safeguards against improper use – currently, even if refspec is wrong, the script will not abort after a failed checkout.

Thanks for posting any improvements you may have.

Source: Tekkub’s post on github discussions.
See also: how to remove a single file from all of git’s commits.

Once I accidentally added circa 300 MiB of archive files to one of my git repositories (which was as small as 5 MiB). I removed those files as soon as I noticed them, but the .git directory still preserved commits with those files, and still occupied over 300 MiB.

I have found the solution at stackoverflow (see also this question).

This method worked for me, but I couldn’t push my rebased repository to the gitosis. I would need to re-init the gitosis repository from my rebased, but I’m not yet prepared to do that.

There is also a slightly different method (which relies on a temporary tag instead of a temporary branch), documented in Git online manual pages; I prefer the temporary branch method.

Below is a full copy-paste of the winning answer by Charles Bailey:

# create and check out a temporary branch at the location of the bad merge
git checkout -b tmpfix

# remove the incorrectly added file
git rm somefile.orig

# commit the amended merge
git commit –amend

# go back to the master branch
git checkout master

# replant the master branch onto the corrected merge
git rebase tmpfix

# delete the temporary branch
git branch -d tmpfix

Also, in my case this thread at stackoverflow was highly useful. I start enjoying the concise and compact style of Charles Bailey :
Read the rest of this entry »

Just a minute ago, I was shocked after logging in to mail.bigmir.net: instead of the bigmir’s own, HTML-only email interface, I got redirected at the gmail’s “Terms and conditions”, after accepting which I found my emails in the classic gmail mailbox.

First thing to think about: at least they did transfer all my emails to the new account.

Second: hey, they had given up their own email interface! Are they leaving the web-portal market of Ukraine? Was the part of their team (which later formed MI6) too important to handle their exodus with no consequences? Is that just a desire to give customers “better” interface and not invest anything into development?

I hope this won’t be a trend, for every service to have Google behind their servers. Or even just behind the name, to avoid extra complexity of having a server.

Finally, I think I’ll get used. But it was only yesterday, that I read the Google anti-utopia, where Big Brother’s name is (evidently) Google, and it’s webcams and microphones and search history define each person’s future AND guilt. Scary…

And I wonder which will be the next service of bigmir.net, “outsourced” like their email.