Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >> > Junio never explained his *TECHNICAL* reason, and Michael Haggerty >> > simply said "there are good technical arguments for and against >> > moving git-remote-hg out of contrib", that was all his explanation for >> > the *TECHNICAL* reason. > >> I am not interested in distinction between technical and social that >> much. The points that were raised in the thread started by John >> Keeping, and some of the points that came to my mind while on that >> thread, even though I may not have mentioned in *that* thread, that >> affected the way *I* thought about the issue are these (not >> exhaustive): > > Let's be clear; the discussion in that thread was contrib vs. core. Most > of the points you mention below are not related to that. > > == contrib vs. core == > > This is the only point relevant to contrib vs. core: > > > - We may be painted in a hard place if remote-hg or remote-bzr take > > us to a position where the Git as a whole is blocked while it is > > incompatible with the other side. > > It will never happen. I already argued against it[1], multiple times. > Essentially making the tests optional removes any possibility of > blockage (pluse many more arguments). I already said that your "It will never happen" is a handwaving, and I already saw you "argued against it". There is no point repeating that exchange. We both know, and bystanders with popcorns in their hands also know, that we have different opinions. You may have been interested in contrib/core in the thread, but that does not prevent others from considering other aspects of the issue and different and possibly better solutions, which was to unbundle. I was very confident back in that thread that the remote Hg bridge would not merely survive but would serve its users well as a standalone project, and the level of confidence was actually a lot higher than for a hypothetical case where other "already in-core" bridges like git-svn/p4 are somehow forced to become standalone, simply because of the difference in the depths of involvement of respective area maintainers. Without meaning any disrespect to Eric or Pete, I think my prodding them (by forwarding issues and proposed patches by others to them when I see them on the list) has been helping the area maintainers who have other time and attention obligations to help us, by drawing their attention and making their workload smaller (they can only Ack and have me apply, instead of maintaining a separate tree). There is a greater risk for these bridges to become unmaintained if we do not have them in my tree, and that would only hurt our users. In the ideal world, it may be better if it weren't that way, but at the same time, new issues that changing time brings to them seem to be handled more or less OK, so we have to be content with the status quo. But I did not see that particular risk at all for the remote Hg bridge. You have been very interested in maintaining it, and I don't think I ever had to prod you to respond to an issue raised on the list. It is an apples-and-oranges comparison to bring up git-svn/p4. Besides, I want to see the "git-core has the best thing among competing implementations for a specific niche subtask" perception changed in the longer term so that it becomes natural for users to say something like "For this particular task, there is no support in what comes with core (or there is a tool that comes with core to address similar issues but in a way different from what you want), and the go-to tool these days for that kind of task is to use this third-party plugin", because it is simply unrealistic to expect my tree to forever be the be-all destination for everything. Things like "git imerge" are helping us to go in that direction. I was hoping that the remote Hg bridge to be capable of becoming the first demonstration to graduate out of contrib/ that shows the users that is the case, not with just talk but with a specific example. Anyway, the above is only within the discussion theme of John Keeping's thread [*1*]. You seem to be adamant that you do not consider other people's opinions that came in later threads you started [*2*], and I do not think that is a sensible way to discuss things. After seeing these discussions, it tells me that the code is not fit for the core (also [*3*]), and I think there no longer is any reason for us to still talk only about contrib vs core. As you already said, you do not want to see them in contrib/, and as you already saw, everybody other than you do not want to see them in core and some of them do not want to even see them in contrib/ for that matter. I do not see that there is any direction other than out. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 *2* http://thread.gmane.org/gmane.comp.version-control.git/248705 *3* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248727 -- 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