Suppose I have such tree:
... -- a -- b -- c -- d -- ...
\
e -- a -- k
and I want it become just
... -- a -- b -- c -- d -- ...
I know how to attach branch name to “e”. I know that what I’m going to do will change history, and this is bad. Also I guess I need to use something like rebase or filter-branch. But how exactly – I’m lost.
Ok. Situation is following: I have rather big tree now (like this)
s -- p -- r
/
a -- b -- c -- d -- e --- g -- w
\ \
t -- p -- l y -- k
but in my one of first commits (like to “b” for ex.) I added binary files, which makes whole repo very heavy. So I decided to take them away. I did it with filter-branch. And Now I have 2 long branches of commits identical to each other starting from second commit.
s -- p -- r
/
a -- b -- c -- d -- e --- g -- w
\ \ \
\ t -- p -- l y -- k
\
\ s'-- p'-- r'
\ /
b'-- c'-- d'-- e'--- g'-- w'
\ \
t'-- p'-- l' y'-- k'
where b’ is commit without binary file in it. So I can’t do merge. I don’t want this whole tree to be in history duplicated so.
After importing a Subversion repository with multiple years of history, I ran into a similar problem with bloat from lots of binary assets. In git: shrinking Subversion import, I describe trimming my git repo from 4.5 GiB to around 100 MiB.
Assuming you want to delete from all commits the files removed in “Delete media files” (6fe87d), you can adapt the approach from my blog post to your repo:
Your github repo doesn’t have any tags, but I include a tag-name filter in case you have private tags.
The
git filter-branchdocumentation covers the--prune-emptyoption.Using this option means your rewritten history will not contain a “Delete media files” commit because it no longer affects the tree. The media files are never created in the new history.
At this point, you’ll see duplication in your repository due to another documented behavior.
If you’re happy with the newly rewritten history, then delete the backup copies.
Git is vigilant about protecting your work, so even after all this intentional rewriting and deleting the reflog is keeping the old commits alive. Purge them with a sequence of two commands:
Now your local repository is ready, but you need to push the updates to GitHub. You could do them one at a time. For a local branch, say master, you’d run
Say you don’t have a local issue5 branch any more. Your clone still has a ref called origin/issue5 that tracks where it is in your GitHub repository. Running
git filter-branchmodifies all the origin refs too, so you can update GitHub without a branch.If all your local branches match their respective commits on the GitHub side (i.e., no unpushed commits), then you can perform a bulk update.
$ git for-each-ref --format="%(refname)" refs/remotes/origin/ | \ grep -v 'HEAD$' | perl -pe 's,^refs/remotes/origin/,,' | \ xargs -n 1 -I '{}' git push -f origin 'refs/remotes/origin/{}:{}'The output of the first stage is a list of refnames:
We don’t want the HEAD pseudo-ref and remove it with
grep -v. For the rest, we use Perl to strip off therefs/remotes/origin/prefix and for each one run a command of the form