Re: RFC: grafts generalised

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 2, 2008, 16:35 UTC
Message-ID: <m3lk0kfdo1.fsf@localhost.localdomain>
In-Reply-To: <20080702143519.GA8391@cuci.nl>

"Stephen R. van den Berg" <srb@cuci.nl> writes:

Show 20 quoted lines

> I'm in the process of converting and stitching and patching vast amounts
> of initially disjunct CVS and SVN repositories into larger complete
> histories inside a single git repository.  Recreating history as
> accurately as possible.
> 
> The problem I encounter is that any number of times I have to "edit"
> history in a non-parameterable fashion, in any of the following ways:
> - Change parents.
> - Add merges.
> - Change author, committer, commitdate, authordate.
> - Change the tree (because of conversion errors in the automated
>   conversion process) belonging to a single commit.
> - Retrofit a patch which has to ripple through all of history until
>   the present.
> 
> The only things which are easily done at the moment are:
> Change parents and add merges.  This can be accomplished fairly easily
> using the grafts file.
> The other changes are messy at best and need to be parameterised into the
> form of a shell script so that git filter-branch can have a go at it.

[...]

Show 18 quoted lines

> I propose the following:
> - Extend git fsck to do more sanity checks on the content of the grafts
>   file (to make it more difficult to shoot yourself in the foot with
>   that file; my feet will be grateful).
> - Extend the grafts file format to support something like the following syntax:
> 
> commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
> Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
> Merge: 3b3da24960a82a479b9ad64affab50226df02abe 13b8f53e8ccec3b08eeb6515e6a10a2a
> Merge: ac719ed37270558f21d89676fce97eab4469b0f1
> Tree: 32fc99814b97322174dbe97ec320cf32314959e2
> Author: Foo Bar (FooBar) <foo@bar>
> AuthorDate: Sat Jun 6 13:50:44 1998 +0000
> Commit: Foo Bar (FooBar) <foo@bar>
> CommitDate: Sat Jun 7 13:50:44 1998 +0000
> Logmessage: First line of logmessage override
> Logmessage: Second line of logmessage override
> Logmessage: Etc.

[...]

First, if I remember correctly (from KernelTrap and now defunct Kernel Traffic and one issue of Git Traffic) the 'graft' mechanizm was created so it would be possible to "graft" (join) historical conversion repository with the "current work" git repository (started from zero when git was deemed good enough for Linux kernel development). The same mechanism is used for shallow clone, where one goes in the opposite direction, shortening history instead of joining two repositories (two histories).

The fact that git-filter-branch (and earlier cg-admin-rewrite-hist) respects grafts, and rewrites history so that grafts are no-op and are not needed further is a bit of side-effect. So I think that it would be better to provide generic git-filter-branch filter which can understand this "generalized grafts" file format, or rather 'description of changes' file. Put it in contrib/, and here you go...

-- 
Jakub Narebski
Poland
ShadeHawk on #git