Jakub Narębski <jnareb@xxxxxxxxx>: > > No, cvs-fast-export does not have --export-marks. It doesn't generate the > > SHA1s that would require. Even if it did, it's not clear how that would help. > > I was thinking about how the following part of git-fast-export > `--import-marks=<file>` > > Any commits that have already been marked will not be exported again. > If the backend uses a similar --import-marks file, this allows for incremental > bidirectional exporting of the repository by keeping the marks the same > across runs. I understand that. But it's not relevant - cvs-fast-import doesn't know about git SHA1s, and cannot. > How cvs-fast-export know where to start exporting from in incremental mode? You give it a cutoff date. This is the same way cvsps-2.x and 3.x worked, and it's what the cvsimport wrapper expects to pass down. > BTW. does cvs-fast-export support incremental *output*, or does it > perform also incremental *work*? As I tried to explain previously in my response to John Herland, it's incremental output only. There is *no* CVS exporter known to me, or him, that supports incremental work. That would be at best be impractically difficult; given CVS's limitations it may be actually impossible. I wouldn't bet against impossible. > Anyway, that might mean that generic fast-import stream based incremental > (i.e. supporting proper thin fetch) remote helper is out of question, perhaps > writing one for cvs / cvs-fe would bring incremental import from CVS to > git? Sorry, I don't understand that. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- 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