> Now that "git rebase" supports non-interactive rebases > preserving merges, this patch is the next logical step > for those who wish to use such a workflow. > > Since this patch makes the last test marked as expecting > failure in t3409-rebase-preserve-merges, we now alter it > to expect success. Does anyone know the current status of this? The first 1/3 and 2/3 of this series is in next now (which grant non-interactive merge-preserving rebasing), but this additional --preserve-merges flag to git pull didn't seem to make it. (Correct me if I'm wrong, I cannot pin point exactly where 1/2 and 2/3 got merged in, I'm just cheating and looking at the files as they exist in next's tip.) My grandeur plan is to have this 3/3 go in as well and then follow it up with my patch to add a branch.name.preservemerges config variable. This will make our internal workflow of "always rebase local changes/always preserve local merges" just work with "git pull". Does this seem reasonable? Thanks, Stephen -- 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
