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
-
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
