On Wed, 19 Sep 2012 02:05:35 -0700 (PDT)
lalebarde <l.aleba...@free.fr> wrote:

> I use Git *smudge/clean* in a border line way that do not respect the
> Git recommendations : "*When you design these filters, they should be
> able to fail gracefully and have the project still work properly."*
> As I change my filters, I wonder if there is a simple method to
> *rebuild completely the repositoty*, in order to have a new one as it
> would have been if this new filter was used from the start - except
> of course the sha1 digests ? I know this is a bad idea, but with some
> care, managing it is possible with suspending the write access to the
> remote for all users but the admin before, notifying all users to
> rebuild, and hook the push with the test of a dummy file that tags
> the filter bersion in order that nobody can push with the old filter.
> I don't want to have to maintain different versions of the filter and
> to embed a version identifier in the smudge filter - only this few
> bytes tag file.
> By rebuild I mean :
> for each commit {
>       smudge each file with the old filter to the workspace or any 
> temporary area
>      clean it with the new filter back to the repository
> }

`git filter-branch` [1] is what you're probably looking for as it
allows one to apply arbitrary script to manipulate each commit on a
branch (or all branches).

Be sure to 1) google for real-world usage examples (stackoverflow
contains pretty few of them, for instance); 2) do this on a cloned
repository, not on your production one as most possibly you will need a
several rounds of trial and error.

1. http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
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