Re: [PATCH] transplant: move a series of commits to a different parent

On Jun 24, 2007, at 12:26 PM, Johannes Schindelin wrote:

Oh! But the commit messages do no longer correspond to their  
patches, do
they?

Example:

In "onto", you have a sorely needed bugfix in main.c. In "from",  
you have
not. Then you do your transplant, and all of a sudden, the
first transplanted commit _undoes_ that bugfix (because you take the
contents at face value), but the commit message _cannot_ say so, or  
even
why.

IMHO this makes no sense (and that is why I misunderstood it as  
being a
rebase).

It doesn't make sense on a sane repository.

I need the script to fix an insane, broken repository that was generated
by git-cvsimport [1]. cvsimport created commits attached to the wrong  
parent
in the first place. So the patches derived from this history are wrong.
They are different from the patches that you'd expect from the cvs  
repository.
The commit messages and the patches did never correspond. My script  
fixes
this relationship. Only after I transplanted the branch the commits and
their messages match.

The following is a different illustration of the same problem.  
Suppose you copy
a file and modify its contents somewhere else. Now you checkout the  
_wrong_
branch, but do not recognize, copy the file back and commit it. You'd be
writing a message as if the right branch would have been checked out.  
This
message describes what you believe you did. But because of the wrong  
branch
you may have done something completely different to the repository.  
You may
for example have reverted earlier changes. Your commit doesn't make  
any sense
before you transplanted it to the right branch. You don't want to  
apply a
patch to the right branch but transplant the content of your file.

	Steffen

[1] http://article.gmane.org/gmane.comp.version-control.git/50736