On Thu, Apr 4, 2013 at 1:23 PM, Jed Brown <jed@xxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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, Really? There have been 22 changes since 3 months ago. You think a project goes from droppable to decent in 22 commits? The fact that you hit a bug doesn't make a project unworthy. I thought you said you were not going to dwell in your value judgement. > but > I think it needs a much more complete test suite [1] and some visible > documentation about its mapping semantics. I don't see anything particularly valuable in gitifyhg's test suite. Show me a single test-case that remote-hg fails that would make sense to port, then we'll talk. > 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. Tell me, what is the worst case scenario a forced push will create? What would be this terrible turmoil? > [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. Oh yes they can, it's very easy to port (although annoying), I ported quite a few of them because it was impossible to debug through py.test (because stderr was incompletely shown), so I was forced to do that, but again, I didn't see much value in them and deleted them. Maybe if we had some complex striping on errors, but not at the moment. I would love to be proven wrong; show me a single test that is so sorely needed in remote-hg. 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