Re: [PATCH 00/13] remote-hg: general updates

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 4, 2013, 19:45 UTC
Message-ID: <CAMP44s2YbJEtpBXHyUGrPta8O8W3fT_TJJ0Cq4BhSJGk1ODPOQ@mail.gmail.com>
In-Reply-To: <87sj36qewa.fsf@59A2.org>

On Thu, Apr 4, 2013 at 1:23 PM, Jed Brown <jed@59a2.org> wrote:

Show 8 quoted lines

> Junio C Hamano <gitster@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.

Show 6 quoted lines

> 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?

Show 5 quoted lines

> [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