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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Am 19.03.2014 um 18:04 schrieb Junio C Hamano <gitster@xxxxxxxxx>:
> 
> Max Horn <max@xxxxxxxxx> writes:
> 
>>> On 17.03.2014, at 18:01, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> 
>>> Torsten Bögershausen <tboegi@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]