Re: History cleanup/rewriting script for git

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Fri, Apr 20, 2007 at 08:39:25PM +0200, Johannes Schindelin wrote:
> On Fri, 20 Apr 2007, Jan Harkes wrote:
> > On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:
> > > On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> > >
> > > > Hmm. However, I have to say that cogito serves/d another purpose 
> > > > quite well: Look at what came from cogito into git. Loads of useful 
> > > > enhancements. So, I really have to point to "at this stage", because 
> > > > that sure was not true 18 months ago.
> > > 
> > > Absolutely. I think there are still some pieces of cogito that we 
> > > might want to migrate into git too, although they're fairly esoteric 
> > > (ie the whole history rewriting thing). And I think we still have some 
> > > places
> > 
> > I actually have a fairly simple history rewriting script (written in 
> > python) that I used when I converted some CVS archives to git.
> 
> Telling by your description, cg-admin-rewrite-hist is more capable. And I 
> think it should not be too complicated to rewrite the cogito specific 
> parts, what with the parts we added to Git with cogito as a model. And it 
> is in Perl... which makes it more portable than Python in my part of the 
> world.

As I wrote this a while ago, before reflogs and packed refs, and I only
needed it for the initial conversion, it only had to write out new
commit objects and retarget branch heads and simple tags. If
cg-admin-rewrite-hist can do better and can be merged into git-core I
would say that is a win-win situation for everyone.

Something like this should be available to allow people to reconstruct
their merge history or fix up empty 'file was added on branch foo'
commits that are left around after the initial import from another VCS.

Personally, I don't think it should ever be used for any published
repositories or branches. Most fixups before publishing can already be
done by rebasing or amending a commit, so this would only be useful for
that intial import where there are in fact a lot of scattered changes
all over the place, or to reconstruct a merge that went bad. But really
in that case, it is probably better to redo the merge correctly and
rebase any commits that might have gone in after the bad merge.

Jan