Johannes Sixt <j...@kdbg.org> writes: > Am 09.02.2015 um 13:53 schrieb Sergey Organov:
[...] > 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. >>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
