Jakub Narebski venit, vidit, dixit 02.07.2008 18:35:
quoted text
> "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...
> 

Maybe the upcoming git-sequencer could be the appropriate place? It 
tries to achieve just that: edit history by specifying a list of 
commands. The currently planned set of commands would need to be 
amended, but the framework should be in place.

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html