Re: RFC: grafts generalised

[Jakub Narebski <jnareb@gmail.com>]

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

> 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.
[...]

> 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