Re: "git pull" throws away dirty state

Nicolas Pitre [off-list ref] writes:

On Sun, 16 Mar 2008, Linus Torvalds wrote:

quoted

On Sun, 16 Mar 2008, Linus Torvalds wrote:

quoted

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?