On Mon, May 9, 2016 at 8:36 AM, Kent Fredric <kentfred...@gmail.com> wrote: > > While you can in theory rebase merge commits with rebase --preserve, > my experience has shown me that its very difficult to get right, and > the presence of merge collisions in the "preserved" rebase risks > getting the conflict resolution lost mid-rebase, which is not entirely > helpful. > > If there was something we could feasibly put hard software policy > constraints against without any subjective "but but but" cases, it > would be these cases of "merge included conflicts". >
Is there any way to tell git to rebase everything but the conflicts themselves, and then resolve those in the merge commit? That might be the cleanest solution as it filters out all the noise, and then has a merge commit which clearly shows how the conflict was resolved. Now, for non-trivial conflicts I think it is better to rebase or merge into the branch, test, and then do a non-conflicting merge back into the main tree. How else will you know that you resolved the conflict correctly? By non-trivial I mean stuff other than keywords and descriptions and such. -- Rich
