On Thu, Apr 4, 2013 at 1:23 PM, Jed Brown <j...@59a2.org> wrote:
> 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,

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.


Felipe Contreras
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

Reply via email to