Re: Merge seems to overwrite unstaged local changes

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 6, 2011, 15:35 UTC
Message-ID: <m3zkhe16bu.fsf@localhost.localdomain>
In-Reply-To: <4E8DACCC.2050302@gmail.com>

Sebastian Schuberth <sschuberth@gmail.com> writes:

Show 21 quoted lines

> On 29.09.2011 15:07, Sebastian Schuberth wrote:
> 
>>> There recently have been quite a change in merge-recursive implementation
>>> and it would be really nice if you can try this again with the tip of
>>> 'master' before 1.7.7 final ships.
>>
>> The unstaged changes do not seem to get lost during the merge anymore
>> when using git version 1.7.7.rc3.4.g8d714 on Linux. I guess that
>> somewhat confirms that there's a bug in git<  1.7.7. I'll write a word
>> of warning to our in-house git users that they should always commit
>> before merging ...
> 
> It seems I'm not the only one who lost code due to this bug. For a
> more detailed analysis see this blog post:
> 
> http://benno.id.au/blog/2011/10/01/git-recursive-merge-broken
> 
> As it turns out, my use case also involves a rename of the file in
> which changes were lost. And just like for the blog's author it
> somewhat concerns me and shakes my confidence in Git for how long this
> severe bug slipped through undetected.

Khmmm... perhaps Mercurial was right in its transaction-based atomicity (that allows to safely merge even if there are local changes; not theough that I have doubts if it is sane behavior) ;-)

I wonder if it would be possible to get some Comp. Sci. student, or graduate, or postdoc, to analyse formally the recursive merge algorithm. And to *prove* that it is correct (or not).

-- 
Jakub Narębski