Linus Torvalds wrote:
On Mon, 25 Jul 2005, Linus Torvalds wrote:
And they are in the wrong order, so "cvsimport" ends up committing the
last one, which is the _empty_ one.
Notice? We'll end up committing "COPYING 1.1" (the empty initial create)
even though we _should_ have committed "COPYING 1.2" (the actual thing
that BK committed).
David, how about a patch like this to cvsps? My very very limited testing
seems to say that it does the right thing..
It's very simple: if we are adding the same file twice to the same
PatchSet, we just look at the ordering of the revisions. If the revision
we're adding is older than the revision we already have, we just drop that
revision entirely. If it's the same, something is really wrong, and we add
it to the "collisions" list. And if it's newer, then we remove the old
revision for that file, and add the new one instead.
As far as I can tell, the old code really was broken, since it would
happen to list different revisions in a random order when you had multiple
changes to the same file in the same patchset. This one always selects the
last one, which would seem to be the sane behaviour.
And this all seem to make "git cvsimport -p --bkcvs" do the right thing.
I've been 'off the web' for a few weeks on vacation. I'll look at the
context of the thread. It 'smells' wierd to have to revisions in the
same patchset at all, but I suppose you've all been through that before.
So let me catch up with this thread and get back to you...
David
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
