Re: [RFC 1/4 v2] Implement a basic remote helper for svn in C.

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 12, 2012, 19:36 UTC
Message-ID: <20120812193640.GA4065@mannheim-rule.local>
In-Reply-To: <1636924.tANzCnKezB@flobuntu>

Hi again,

Florian Achleitner wrote:

> Another alternative would be to use the existing --cat-pipe-fd argument. But 
> that requires to open the fifo before execing fast-import and makes us 
> dependent on the posix model of forking and inheriting file descriptors

Let me elaborate on this, which I think is the real point (though I could easily be wrong).

Probably instead of just sending feedback I should have been sending suggested patches to compare. You do not work for me and your time is not my time, and I would not want to have the responsibility of dictating how your code works, anyway. Generally speaking, as long as code is useful and not hurting maintainability, the best thing I can do is to make it easy to incorporate. That has side benefits, too, like giving an example of what it is like to have your code incorporated and creating momentum. Small mistakes can be fixed later.

Unfortunately here we are talking about two interfaces that need to be stable. Mistakes stay --- once there is a UI wart in interfaces people are using, we are stuck continuing to support it.

To make life even more complicated, there are two interfaces involved here:

 - the remote-helper protocol, which I think it is very important
   to keep sane and stable.  Despite the remote-helper protocol
   existing for a long time, it hasn't seen a lot of adoption
   outside git yet, and complicating the protocol will not help
   that.

   I am worried about what it would mean to add an additional
   stream on top of the standard input and output used in the current
   remote-helper protocol.  Receiving responses to fast-import
   commands on stdin seems very simple.  Maybe I am wrong?

 - the fast-import interface, which is also important but I'm not
   as worried about.  Adding a new command-line parameter means
   importers that call fast-import can unnecessarily depend on
   newer versions of git, so it's still something to be avoided.

Given a particular interface, there may be multiple choices of how to implement it. For example, on Unix the remote-helper protocol could be fulfilled by letting fast-import inherit the file descriptor helper->in, while on Windows it could for example be fulfilled by using DuplicateHandle() to transmit the pipe handle before or after fast-import has already started running.

The implementation strategy can easily be changed later. What is important is that the interface be pleasant and *possible* to implement sanely.

Hoping that clarifies a little, Jonathan