Re: [PATCH] Improve documentation for git-remote-helpers

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 22, 2010, 00:06 UTC
Message-ID: <alpine.LNX.2.00.1003211951360.14365@iabervon.org>
In-Reply-To: <fabb9a1e1003211635w27f0b22em73c7c6431c3998af@mail.gmail.com>

On Mon, 22 Mar 2010, Sverre Rabbelier wrote:

Show 18 quoted lines

> Heya,
> 
> On Mon, Mar 22, 2010 at 00:29, Daniel Barkalow <barkalow@iabervon.org> 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*