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