Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)

[Junio C Hamano <gitster@pobox.com>]

Max Horn <max@quendi.de> writes:

> On 17.03.2014, at 18:01, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Torsten Bögershausen <tboegi@web.de> writes:
>> 
>>> On 2014-03-14 23.09, Junio C Hamano wrote:
>>>> * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
>>>> - remote-hg: do not fail on invalid bookmarks
>>>> 
>>>> Reported to break tests ($gmane/240005)
>>>> Expecting a reroll.
>>> I wonder what should happen here.
>>> The change breaks all the tests in test-hg-hg-git.sh
>>> (And the breakage may prevent us from detecting other breakages)
>>> 
>>> The ideal situation would be to have an extra test case for the problem
>>> which we try to fix with this patch.
>>> 
>>> Antoine, is there any way to make your problem reproducable ?
>>> And based on that, to make a patch which passes all test cases ?
>> 
>> After re-reading the thread briefly (there're just five messages)
>> 
>>  http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069
>
> For some reason, that link does not contain all messages from that
> conversation (unfortunately, I have seen GMane do that on multiple
> occasions. I hence try not to rely on it for reviewing email
> history -- I just don't trust it). In particular, it misses this
> crucial post:

[jc: please avoid overlong lines; I re-flowed above]

>   http://thread.gmane.org/gmane.comp.version-control.git/239830

Interesting.

> The (or at least "a") root cause has actually been
> discovered. Would a patch that adds an xfail test case for it be
> acceptable?

Do you mean a patch that only adds a new test that expects a failure
to the current code, without touching the current code that has the
bug it exposes?  That would be a good place to start.

> ... As a matter of fact, I a know a few more bugs in remote-hg for
> which I could produce xfail test cases. Of course I'd prefer to
> put them in together with a fix, but I don't know when I can get
> to that, if ever. So, would such changes be welcome?

Surely.  That is to keep tabs on bugs in an actionable form; it is a
better way of bug tracking than having a bug-tracker that is not
actively maintained, I would think.