> Am 19.03.2014 um 18:04 schrieb Junio C Hamano <gits...@pobox.com>: > > Max Horn <m...@quendi.de> writes: > >>> On 17.03.2014, at 18:01, Junio C Hamano <gits...@pobox.com> wrote: >>> >>> Torsten Bögershausen <tbo...@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]
Sorry. If anybody knows a way to tech Mail.app to auto-wrap long lines, I'd appreciate a hint. > >> 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? Exactly. > That would be a good place to start. Ok. > >> ... 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. Yeah, makes sense. So, one more silly (bikeshedding) question: should I do this as one big patch adding multiple xfail tests - or one commit per test, with perhaps a brief description of the issue at hand? Or should a code comment next to the failing test explain things? Actually, some of those bugs might require a lengthy background explanation, so yet another variant would be to write an email here With an explanation, then add a gmane ref to the commit message... > > > > -- 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
