Johannes Sixt <j6t@xxxxxxxx> writes: > When rebase -p had to replay a merge commit, it used to redo the merge. > But this has drawbacks: > > - When the merge was evil, i.e., contained changes that are in neither of > the parents, that change was not preserved. This is a desiable property, and not necessarily limited to "evil" merges but also applies to everyday conflict resolutions. Replaying the change between the merge and its first parent is a way to achieve it, but I think it also has downsides. If you are replaying a merge to an updated history that already contains a part of what is merged, some part of the difference between the original merge and its first parent already exists in the commit that the will become the first parent of the replayed merge. > - The 'git merge' invocation passed the commit message of the old merge > commit, but it still obeyed the merge.log option. If it was set, the log > ended up twice in the commit message. This should be fixed independent of this patch, no? Is it a matter of just passing --no-log or something, or is there anything more elaborate necessary? -- 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