Re: 'git rebase' silently drops changes?

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 9, 2015, 19:03 UTC
Message-ID: <54D90473.2090208@kdbg.org>
In-Reply-To: <87oap38cv1.fsf@osv.gnss.ru>

Am 09.02.2015 um 13:53 schrieb Sergey Organov:

Show 21 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:
>>> On 06.02.2015 22:28, Sergey Organov wrote:
>>>
>>>> # Now rebase my work.
>>>> git rebase -f HEAD~1
>>>>
>>>> # What? Where is my "Precious" change in "a"???
>>>> cat a
>>>> </SCRIPT>
>>>>
>>>> I.e., the modification marked [!] was silently lost during rebase!
>>>
>>> Just a wild guess: Maybe because you omitted "-p" / "--preserve-merges"
>>> from "git rebase"?
>>
>> No, that would not help. --preserve-merges repeats the merge, but does
>> not apply the amendment.
> 
> Really? Why? Here the valid concern you gave below doesn't even apply!

--preserve-merges was bolted on to git-rebase. The first implementation just re-computed the merge, and rebase would be interrupted if the merge was not clean. This was good enough for many.

Later --preserve-merges was abused to replay not only integration branches, but branchy history in general. At that time, the feature was deemed wide spread enough that changing its behavior was a no-go.

There you have it.

If you want a version of --preserve-merges that does what *you* need, consider this commit:

  git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent

Use it like this:

  git rebase -i -p --first-parent ...

Beware, its implementation is incomplete: if the rebase is interrupted, then 'git rebase --continue' behaves as if --first-parent were not given.

Show 8 quoted lines

>> it is impossible for git rebase to decide to which rebased
>> commit the amendement applies. It doesn't even try to guess. It's the
>> responsibility of the user to apply the amendment to the correct
>> commit.
> 
> Yeah, this sounds reasonable, /except/ git even gives no warning when it
> drops amendments. Shouldn't 'git rebase' rather consider merge amendment
> a kind of conflict?

There is work in progress where a merge is computed entirely in-memory (without relying on files in the worktree). It could be used to detect whether there are any changes beyond the automatic merge results, and they could be warned about.

-- Hannes