Sebastian Schuberth <sschuberth@xxxxxxxxx> writes: > 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 -- 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