Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 19, 2014, 17:04 UTC
- Message-ID
- <xmqqlhw65dcq.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <906CACC0-FB16-4BB8-812D-59067DE0CC89@quendi.de>
Max Horn <max@quendi.de> writes:
Show 29 quoted lines
> 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.