Re: Merge seems to overwrite unstaged local changes

Sebastian Schuberth [off-list ref] writes:

On 29.09.2011 15:07, Sebastian Schuberth wrote:

quoted

quoted

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