> The one thing I worry about is that you are proposing to wait a while > before submitting your changes upstream. I would suggest pushing > whatever pieces work to contrib/ early on to get more feedback from > reviewers and testers. (I am saying this selfishly, as a potential > tester.) Okay, I'll try to get patches integrated immediately then. > The structure for remote helpers should be that each foreign system has a > single helper which git can call with instructions on what to do (both for > foreign-to-git and for git-to-foreign operations). So 3 and 4 have to be > functions of the same program, and it's probably best for 2 and 5 and > maybe 1 to also be part of this program. Right. I only split it up for the purposes of illustration. 3 and 4 will be merged into a program called `git-remote-svn` that will automatically be invoked when Git encounters an SVN remote. 2 and 5 will be merged into another program `svn-export-import` which can be thought of as the fusion of svn-fast-export and svn-fast-import. `git-remote-svn` will invoke it when necessary. And yeah, I don't know if I want to write the SVN client into `svn-export-import` or leave it as a separate program. > So the helper wouldn't be running git-fast-export or git-fast-import, > unless it was a helper for using git as the foreign system. Ah. I just realized that :) > If you're going to work in C, you should look at my Perforce helper. It's > suitable for mainline inclusion, due to using a free-as-in-beer, > made-available-without-license-terms C++ library for the Perforce side, > but may be a better model for a C remote helper than git.py is. Thanks. I'll have a look. git.py isn't very useful. Regards, Ramkumar -- 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