On Tue, 13 Jun 2006, Jim Meyering wrote: > > Here's a test case that shows how git-cvsimport is misbehaving. > The script below demonstrates the problem with git-1.3.3 as > well as with 1.4.0.rc2.g5e3a6. As for cvsps, I'm using version 2.1. Well, it's a cvsps problem. Big surprise. Sadly, it also seems to be one that isn't fixed by the patches _I_ have, and looking at Yann's set of patches, I don't think they fix it either. This is what (my version of) CVSps reports for your repository: --------------------- PatchSet 1 Date: 2006/06/13 10:06:42 Author: torvalds Branch: HEAD Tag: (none) Log: . Members: on-br:INITIAL->1.1 on-trunk:INITIAL->1.1 --------------------- PatchSet 2 Date: 2006/06/13 10:06:44 Author: torvalds Branch: B Ancestor branch: HEAD Tag: (none) Log: . Members: on-br:1.1->1.1.2.1 --------------------- PatchSet 3 Date: 2006/06/13 10:06:46 Author: torvalds Branch: HEAD Tag: (none) Log: . Members: on-br:1.1->1.2(DEAD) and note how the "on-br" file is part of the initial PatchSet 1. So CVSps basically tells git-cvsimport that commit 2 (on branch B) is based on commit 1, and doesn't say that "on-trunk" has gone away, so the resulting git repository has branch B containing "on-trunk" version 1.1, and "on-br" version 1.1.2.1. CVS branches obviously sometimes confuse CVSps. Sadly, they also confuse _me_, so I don't see how to fix this particular CVSps bug, because I'm as confused as CVSps is ;) We'd need to have CVSps tell git that the "on-trunk" file was never added to branch B: the simplest way to do that would be to say that it has become (DEAD) in PatchSet 2 (which is not technically true in CVS terms, but _is_ technically true on git terms - on branch B, that file is obviously dead). Yann? Pavel? Anybody? Ideas? Linus - : 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