On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >> >>> Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. >>> >>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. >> >> Thanks. Will queue on 'pu' without looking. > > Actually, I was going to merge fc/remote-hg and fc/remote-bzr down > to master anyway, so I'll just apply them directly on 'master'. > > By the way, I personally do not think the quality of the changes to > remote-bzr matters all that much at this point in its history. It's > not like millions of people use it heavily from the v1.8.2 release. > A huge patch series from its original author and nobody else, either > reviewed or unreviwed, would not hurt them more than the one in the > v1.8.2 version anyway. And it is also not like bzr-to-git population > will grow significantly in the future to require us to pile a lot of > features on remote-bzr that makes the maintenance burden of it > becomes an issue. > > Am I underestimating the pain of potentially breaking existing > remote-bzr userbase? No, I think it's reasonable. 1.8.2 was better because 1.8.1 didn't ave any support whatsoever, and 1.8.3 will be better, because 1.8.2 was barely usable for any real-world project. Will there be any regressions? I doubt it, and if there are, it's unlikely that they would be found in the review process, in 'pu', or in 'next', specially since very few people actually use remote-bzr, in part because it wasn't very useful, and in part because few people use bzr in the first place. Of course, I would prefer if people reviewed the patches for the massive changes, the _important_ patches, and I would gladly explain the reasoning and update the commit messages if needed. But nobody is volunteering to review that. The only exception was for a few irrelevant patches that could be easily dropped. remote-hg is a different story, and so I'm being more careful with the changes there, and I actually think the current patches are more than enough for 1.8.3, they should be tested in an actual release, and the rest would have to wait. For the rest, I'm still juggling in which order I should send them, and I want to send first the ones that should maximize the benefits for the users, with minimum possibility of breakage, but even then I wouldn't be confident with those landing in 1.8.3, so 1.8.4 it is. Cheers. -- Felipe Contreras -- 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