Show 28 quoted lines
>
> 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