On Mon, 22 Mar 2010, Sverre Rabbelier wrote: > Heya, > > On Mon, Mar 22, 2010 at 00:29, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > Yup. Or maybe these should be documented as a list of capabilities which > > mean that the helper supports the command with the same name, since that's > > a common pattern, and documenting it as a pattern makes it obvious that, > > if we have a new 'export' command, and it needs a capability, it'll fit > > the pattern. > > Speaking of which, I have uploaded a preliminary version of the export > capability to my github repository [0] since Ramkumar wanted to have a > look at it. Sadly I have not been able to test it yet, I wanted to > work on that today but instead spent hours on getting the first > argument to the helper to be 'origin' (or whatever the user sets it to > with the --origin option), something that's been bothering me forever. > No documentation yet though, working on that ;). > > [0] http://github.com/SRabbelier/git Looks generally right, but I think you need to do "finish_command(&exporter);" first, and actually get some feedback from the helper. I think the right thing is actually to put the output of the helper into fast-import again, and have that give one of three conclusions: - We tried to send sha1 A to the foreign system, and it rejected us entirely. - We tried to send sha1 A to the foreign system, and reimporting what it put in for us actually gives us sha1 A, so the transformation is lossless. - We tried to send sha1 A to the foreign system, but reimporting what it put in for us gives us sha1 B instead. This means B is as close to a replacement for A as we can get in this case, and the git core should know about the situation (although, for now, it doesn't have anything to do about it). At the least, in the third case, we should update any tracking branches to match what the foreign system now contains, not to match what we tried to put there. But even without considering the third case (IIRC, hg and git can interoperate losslessly), you need to get feedback in some way if the remote entirely rejected us. -Daniel *This .sig left intentionally blank* -- 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