Re: Merge seems to overwrite unstaged local changes

Sebastian Schuberth [off-list ref] writes:

... I'm seeing this on Linux and Windows, with versions 1.7.4.3 and 1.7.6.

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.

Thanks.

On Wed, Sep 28, 2011 at 17:25, Junio C Hamano [off-list ref] wrote:

quoted

... I'm seeing this on Linux and Windows, with versions 1.7.4.3 and 1.7.6.

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

-- 
Sebastian Schuberth

On 29.09.2011 15:07, Sebastian Schuberth wrote:

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.

-- 
Sebastian Schuberth

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

3 hours-worth of work just got whacked by this bug. Unimpressed :-(

Could have been worse I suppose. Thanks for the confirmation.

<Goes to update Git>