Nicolas Pitre <nico@xxxxxxx> writes:
> On Sun, 16 Mar 2008, Linus Torvalds wrote:
>
>> On Sun, 16 Mar 2008, Linus Torvalds wrote:
>> >
>> > Ok, this is distressing, and I suspect it's another bug of mine due to
>> > unpack-trees changes, but before I delve into it deeper I thought I'd
>> > report it here and see if others see it too, and maybe it's due to
>> > something else..
>>
>> Nope, I bisected it down to
>>
>> 34110cd4e394e3f92c01a4709689b384c34645d8 is first bad commit
>>
>> Make 'unpack_trees()' have a separate source and destination index
>>
>> and I'm trying to figure out what part of that triggered this bug.
>
> We really should have more tests to cover all those bugs that were
> introduced and fixed lately.
>
> Given that Git should work fine in some cases even with a dirty work
> tree by design, I'm a bit surprised that we don't have any test case
> covering that.
Yeah, I was wondering why these are not covered by
t/t1000-read-tree-m-3way:
"git read-tree -m O A B"
O A B result index requirements
-------------------------------------------------------------------
12 exists O!=A O!=B take A must match A, if exists.
A==B
------------------------------------------------------------------
13 exists O!=A O==B take A must match A, if exists.
------------------------------------------------------------------
14 exists O==A O!=B take B if exists, must either (1)
match A and be up-to-date,
or (2) match B.
------------------------------------------------------------------
But this one tests only "read-tree -m", not "read-tree -m -u". The tests
for "-m -u" we have in t1004 is not about being comprehensive like t1000
(which covers all cases in the case table) but seems to be more about
randomly selected cases.
Patches?
--
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
