On 03/18/2018 05:04 AM, Pavel Sanda wrote: > Richard Kimberly Heck wrote: >> On 03/17/2018 10:28 PM, Scott Kostyshak wrote: >>> On Sat, Mar 17, 2018 at 08:01:58PM +0000, Richard Kimberly Heck wrote: >>>> Commits intended for 2.3.1 should now just go to 2.3.x, with my nod, as >>>> usual. Note that 2.3.2-staging is still live. >>> How did you do the merging? I'm surprised there was no merge commit. Was >>> that because it could be rebased? I'm just curious. >> Yes, I rebased before merging. Magic, that. > Does not rebasing public branch break history for other people working with > 2.3.x branch?
The rebase was of 2.3.1-staging, not of 2.3.x. And it never got committeds, so nothing public changed. Basically, I did exactly what I always do with git branches I create for features or bug fixes: git checkout -b BugBranch ...do lots of things until it's ready.... git checkout -b BugBranch-rebase git rebase master ...fix that up some if need be.... git checkout master git merge BugBranch-rebase The result is that the new commits in BugBranch just appear on top of master. On 03/18/2018 10:02 AM, Scott Kostyshak wrote: > That said, I would actually prefer a "merge --no-ff". I had not heard of that but agree it might have been preferable. Richard
