On Jan 2, 2011, Richard Stallman <r...@gnu.org> wrote: > This operation is clean and general, so they might even install it.
It's so clean and general that it's already implemented in git. It's called “git filter-branch”, in the way you stated, or “git rebase”, for a more manual implementation (maybe good to create an initial mapping). What git misses is means to restore compatibility between the original and the rewritten branch. This prevents others from using our repository and “git pull”ing other's topic branches. This is the problem I'm trying to solve, because I don't see that our repository would be useful otherwise. I don't expect lots of Linux developers to switch to a libre repository if this will make it less likely for their developments to be “git pull” ed by Linus or Andrew Morton, or for other users to switch to it if they will then have trouble when pulling others' patches. That said, having a properly filtered repository is a precondition for this once git pull is improved so as to support rewritten branches, so I might as well get started with it as time permits. It's not like it will be wasted time, and it might show I'm wrong in my assessment of usefulness. But it's certainly not as interesting, hack-wise, as finding a way for git to do the work we need, so I tend to be more attracted to the latter. It doesn't help that we don't have scripts yet to deblob such early releases of Linux as 2.6.11, when the history started. If we did, the entire process would be relatively simple. Now, once I get to that, we might not even need those scripts, and just release out of the git repository, so... I'm beginning to like this more and more ;-) -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer