[core-workflow] GitHub Workflow

[Oleg Broytman]

On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at 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.

   Fixup (during an interactive rebase) combines commit messages.

> 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.

   Me too. I have never used squashed merge. But "branchiful"
development has its own troubles like problems with bisect.

> ChrisA

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.