Hi Peff, On Wed, 31 Oct 2012, Jeff King wrote: > I really like some of the directions the series is taking, and as the > maintainer, I'd like to pick it up. Code-wise, I agree. > 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)? Disclaimer: I do not know the details (as I said, I have higher priorities elsewhere since the remote-hg I need for everyday work continues to do its job, and the patch series bringing Python to msysGit is more pressing, and I will enjoy its review much more, too). The biggest advantage seems to me that it was started later than msysGit's remote-hg and as such could potentially exploit recent improvements in git.git. > - 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 biggest advantage msysGit's series has is that it had a fix for a fundamental flaw in fast-export. Fast-export was intended to work incrementally, so the incantation "git branch blub master && git fast-export ^master blub" is expected to update the ref "blub" properly. I just tested this with junio/next and it seems this issue is still unfixed: instead of reset refs/heads/blub from e7510461b7db54b181d07acced0ed3b1ada072c8 I get reset refs/heads/blub from :0 when running "git fast-export ^master blub". Having said that, we have no problem to throw away the fix that was rejected by Junio (who wanted something much more general which I refused to implement both due to lack of time and lack of need -- think YAGNI) and rebase our stuff on top of whatever goes into git.git's next (or master, we are still deciding in the msysGit project whether we should stop tracking next). Another thing that I really like about remote-hg as it is in msysGit is that it was designed with extensibility in mind. It should not be too hard to support other fast-import/export based backends using that infrastructure. I am particularly interested in bzr myself, but there is no day-job related project I could use as an excuse to give that project a higher priority that the other things I am doing at the moment. > - 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? Junio wanted a more general solution, adding infrastructure to the rev-list engine that I did not need -- and did not see the need for, either -- and given the amount of time I had invested in a working remote-hg and given that I needed it desperately for my day-job project, I decided to just put it into msysGit and give up my hopes for it to become official. It has worked well in the meantime and met my needs. The only thing missing is the support for octopus merges. But I would need that only to satisfy my geek self: I would set up an automatic Hg mirror of git.git itself on bitbucket. > 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? Hopefully my attempt met your expectations. Thank you, Dscho -- 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