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.

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 :

# detach head and move to D commit
git checkout

# move HEAD to A, but leave the index and working tree as for D
git reset –soft

# Redo the D commit re-using the commit message, but now on top of A
git commit -C

# Re-apply everything from the old D onwards onto this new place
git rebase –onto HEAD master

Note: this example is for a branch of commits R–A–B–C–D–E–HEAD, where commits B & C should be removed from commit history.

Another option is to use git rebase –interactive (for the same example):

git rebase -i HEAD~5

Unfortunately, rebasing on a public (pushed out) branch has no effect for other users of the current gitosis repository.

An alternative to re-initializing gitosis repository from rebased scratch could be switching to a different (rebased) branch, and deleting the outdated master branch; but I haven’t investigated if this works.

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.