Re: 'git rebase' silently drops changes?

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 10, 2015, 11:46 UTC
Message-ID: <87pp9ivvir.fsf@osv.gnss.ru>
In-Reply-To: <54D90473.2090208@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

> Am 09.02.2015 um 13:53 schrieb Sergey Organov:

[...]

Show 8 quoted lines

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

Thanks a lot, this sounds promising! I've read the message for this commit and it mentions no drawbacks. Are you aware of any?

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

Just never did get round to it, or something more fundamental?

To be useful for me, it also needs a support for 'git pull' to pass this flag to 'git rebase', but that I think I can easily fix myself.

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

Nice to hear there are chances to improve this in the future.

Thanks again!

-- Sergey.