On Monday, September 3, 2012 7:18:14 AM UTC+2, Walt Destler wrote:
> I have two Git repositories which I'll call *A* and *B*. Repo *B* happens 
> to be a submodule of Repo *A*.
> Repo *B* is chock full of binary files that I'd like to wipe from 
> history. (These are private repos so I won't be screwing anyone else up by 
> changing history.) I can easily run a branch-filter command to erase those 
> files from repo *B*'s history. That's not my problem.
> My problem is that, after running branch-filter on repo *B*, thousands of 
> commits in repo *A* will now point to (now-invalid) commits in repo *B*.
> So my question is: How do I modify the history of repo *A* so that each 
> commit of repo *A* points to the correct commit of repo *B*, after having 
> run branch-filter on repo *B*?

Hm, that sounds tricky. Conceptually you would need to hook into 
filter-branch, and after each commit-rewrite in repo *B*, dive into *A*, 
find all commits that reference (via .gitmodules) the re-written *B *commit, 
and rewrite them.

Filter-branch offers you to execute a command after each rewritten commit, 
and in this command you can use $GIT_COMMIT to reference the commit in *B 
is currently being rewritten. However, you also need the rewritten commit 
SHA. and I'm not sure how you can get hold of that.

I see that filter branch has 

A map function is available that takes an "original sha1 id" argument and 
> outputs a "rewritten sha1 id" if the commit has been already rewritten, and 
> "original sha1 id" otherwise

Maybe you could use this somehow to get hold of the rewritten commits. I 
can't really say as I'm not sure how to use this function.

In the end though, does it really matter if older revisions of A reference 
non-existing commits in the .gitmodules? As long as the current values are 
correct, your submodules will still work. 

And of course, you can also go through the old changes to .gitmodules with 
git rebase --interactive and change the SHAs manually.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to