Hello, (this is my first message on this list, so hello everybody. I hope I found the correct channel.) I recently discovered the --preserve-merges option in git rebase, I think it is nice, but it does not always do what I intend. I am proposing a variation of this option which would behave differently. ## Use case We have an acceptance branch that is frequently rebased on master. At any given time, the acceptance branch should start with master, and then merge in those feature branches that were selected for acceptance testing. Nobody is supposed to work on acceptance, it is only meant for deployment on the acceptance server. This means we need a rebase operation where: - The commits of the acceptance branch itself are being replaced. - The commits of the feature branches remain as they are. A "git rebase --preserve-merges" almost does this, but not really. ## Proposal Add a new option for rebase, similar to --preserve-merges, where: Instead of "git pick MERGE_COMMIT", we get this line in the rebase editor (if using the -i option): exec git merge MERGE_COMMIT^2 -m"Merge FEATURE_BRANCH into acceptance." In --interactive / -i mode, the developer can leave these lines as they are, or replace them manually to merge a more recent version of the feature branch. E.g. replace this exec git merge MERGE_COMMIT^2 -m"Merge FEATURE_BRANCH into acceptance." with this exec git merge FEATURE_BRANCH_RECENT This would achieve the behavior as described in "Use case". I have not thought about a name for this option yet, I first want to see some general feedback. Possibly related: https://public-inbox.org/git/87y3jtqdyg.fsf@xxxxxxxxx/ I think the author of this RFC has different expectations what a rebase should do, so it is not really the same. ------------ I hope this was the correct way to propose this kind of feature. If not, let me know where I can find more information. Greetings, Andreas Hennings https://github.com/donquixote
