Junio C Hamano <gits...@pobox.com> writes: > So,... is there a concrete proposal for _me_ to act on? Do you want > to see contrib/remtote-hg out of my tree, and have it compete with > the other one (which also shouldn't be in my tree) in the open?
Three months ago, I would have said yes. Now I don't know. It looks like remote-hg has improved and is perhaps stable enough to remain, but I think it needs a much more complete test suite [1] and some visible documentation about its mapping semantics. There is no way a change like "force-push by default" should come without the user knowing about it. (I don't think force-push should become the default in any case, but something is wrong with the process if there isn't a good way to communicate such behavioral turmoil.) A separate project making its own releases has a more visible place to indicate such changes. [1] Max and I have no love for the "obfuscated shell scripting" in gitifyhg's 'py.test'- and 'sh'-based test suite, and we expressed early on that we'd rather have git-style shell scripts. So while porting these would provide a good start, they can't just be dropped into git.git. -- 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
