On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd@phdru.name> wrote:
I don't understand the cherry-pick: why not just merge the rebased feature branch with 'git merge --squash', and fix up the changelog in the commit message of the merge commit?
That would require a lot of manual editing of the commit message while interactive rebase and cherry-pick preserve messages.
There are some definite oddities to the workflow. For instance, using "reword" followed by "fixup" lets you edit the original commit's message, but without any reference to the subsequent commits; in contrast, using "squash" would have shown all the messages - and every version of git that I've ever used has permitted a squashed commit's message to be edited, so either that's super old or there's some other reason for this. Personally, I don't believe in squashing the commits of a PR/merge (I see the sub-history as important, not just the history of "this feature was merged in" - although for trivial changes, where there's one simple commit and then a follow-up to fix a typo or something, maybe it's tidier), but if that's what you want, I'd simply rebase the feature branch to squash it (at the same time as rebasing it onto the latest master), and then merge. Way WAY simpler. ChrisA