Re: "git pull" throws away dirty state

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 16, 2008, 20:50 UTC
Message-ID: <7vprtuieb4.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.00.0803161434450.2947@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 23 quoted lines

> 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?