Jakub Narebski venit, vidit, dixit 02.07.2008 18:35:
"Stephen R. van den Berg" <srb@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
