Am 09.02.2015 um 13:53 schrieb Sergey Organov: > Johannes Sixt <j6t@xxxxxxxx> 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. >> 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 -- 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