On Wed, Oct 31, 2012 at 11:27 AM, Jeff King <p...@peff.net> wrote: > On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote: > >> 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)?
>From the top of my head: * Support for tags * Support for bookmarks * Support for hg-git compatibility * Extensive tests (truly extensive) * _Much_ simpler code * No dependencies But let's forget about msysgit, because it's not really clear what series of patches we are talking about. If we want to make a real try, and a real comparison, we need a clear set of patches, which seem to be available only on Max Horn's repo[1]. > - 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? Honestly I am not aware of anything we would loose. > - 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 explained that already. If indeed I was looking at the right commits, then I already sent patches that tackle, or otherwise deal with the very same problems (albet in much simpler way). These patches should have held the code, as they are not _needed_ but merely improving things. The rest of the patches would barely make any difference. This is of course my guess by reading the code, I have not tried it. In short, only this patch helps: http://article.gmane.org/gmane.comp.version-control.git/208729 And the rest of the code should work just fine on top of latest git.git. > 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? Let me try to summarize the situation: Johannes is not willing to collaborate, and nobody else has offered to push forward the patches in msysgit. > 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. I also would like somebody to compare the two, so that we can have healthy competition, and hopefully also cooperation. But that doesn't seem to be likely. So, what to do? Should I be the one making an analysis of that code? Since nobody else is willing to try to compare the two, I don't see many other choices, but when/if my conclusion is that my version is superior, I presume nobody would take my word for it, so what would be the point? Cheers. [1] http://github.com/fingolfin/git/tree/remote-hg -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
