I've been converting some old CVS repositories to git, and as it turns
out, these repositories consist of a number of main branches of the same
project that were created at several points in time (the stable release
branches), and the branches contain numerous backports (and a few
forward ports) between each other.
I.e. the branches split off each other at various points in time, and
evolved independently ever since (except for the numerous backports).
Now, the backports can be implemented using a mere "git cherry-pick -x",
but that creates this silly text references to the original commits.
I'd rather use something that gitk can visualise.
So I tried to use the parents of the commit to reference the origin(s).
I.e. the first parent links to the linear history on a given branch, but
the second (and possibly more) parents point to the cherry-picked
back-ported commit from another branch. This graft-constructed
repository is then fed to filter-branch to make it permanent.
To view it try: git://pike-git.lysator.liu.se/pikex
This works quite well and shows the following results:
- gitk shows proper grafts.
- gitk properly shows a zero-diff between the new commit and the
commits we cherry-picked from.
- It even works perfectly when picking from multiple parents.
- gitk is confused in its display of tags preceding and following this
commit (depending on the situation it mixes up the branches).
Obviously the reason it works rather well is because git can actually
distinguish between a merge and a backport because of the way the
contents of the trees change.
The questions now are:
- Would there be good reason not to record the backport/forwardport
relationship in the additional parents of a commit?
- Since most of the git machinery (git diff, and gitk, most notably)
seem to work just fine when using parents for that purpose, would it
be acceptable to create a patch to cherry-pick to support an option to
record the backport/forwardport relationship in the second (or more)
parent field(s)?
- And depending on an affirmative on the previous question, would it be
acceptable to teach the gitk preceding/following tag listing to deal
with these backport/forwardports ?
--
Sincerely,
Stephen R. van den Berg.
"The future is here, it's just not widely distributed yet." -- William Gibson
--
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
