Re: [PATCH v4 00/13] New remote-hg helper

From: Jeff King <peff@peff.net>
Date: Oct 31, 2012, 10:27 UTC
Message-ID: <20121031102712.GB30879@sigill.intra.peff.net>
In-Reply-To: <5090EFCA.7070606@drmicha.warpmail.net>

On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote:

Show 6 quoted lines

> For the record, Johannes is not the only one being kept from looking at
> this series (further) by the tone of this discussion. Per hominem
> attacks are neither professional nor helpful. We prefer to discuss code
> here, just code. From my comments on an earlier version of your series
> you can see I've tried. The way other comment threads on this series
> unfolded made me choose to be a mere by-stander again.

Me too. I really like some of the directions the series is taking, and as the maintainer, I'd like to pick it up. But there is a big question mark for me still about how it relates to the work in msysgit, especially:

  - What advantages does this implementation have over the one in
    msysgit (i.e., new features that the other one does not have)?

  - What disadvantages? If this implementation goes into git.git,
    the msysgit one is likely to wane in popularity. What will we be
    losing by doing so? If the answer is not "nothing", how hard would
    it be to port over the missing bits?

  - The msysgit one got held up by fixes needed for fast-export. Why
    aren't those a problem for this implementation? If we are using a
    different strategy that avoids the issue, what are the limitations
    (if any) of that strategy?

I have a feeling that some of those answers are buried deep within the discussion, but I have had a hard time following all of the back and forth due to the volume and tone of the discussion. Are we at a point now where some of the participants can try to summarize the situation?

I am not saying that this implementation must be 100% better than the msysgit one. I do not want perfect to to be the enemy of good and end up with nothing. But at the same time, there really are two competing implementations, one of which has received substantially more field use. Even though the msysgit one is not in git.git, it seems like the path for making it happen exists (even if it has not been followed yet). Before merging an alternative implementation, I would want to know what we are potentially throwing away from the msysgit side, and make sure that we are not following a wrong path that msysgit has already tried and found to be lacking.

-Peff