[core-workflow] GitHub Workflow

[Oleg Broytman]

On Fri, Mar 18, 2016 at 05:14:52AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd at phdru.name> wrote:
> > 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.
> 
> Fixup discards the subsequent message(s); it's absolutely awesome for
> the case where your initial message was perfect (eg when you're
> patching in a typo fix or something), but for this workflow, they're
> editing the message anyway.

   Ah, yes, it's "squash", not "fixup".

> >> 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.
> 
> Yes, it does. Most of the time, you can just rebase the commits into a
> linear history and run with it; since git retains separate Author and
> Committer names and timestamps, you can give proper credit to the
> contributor, while still ordering things appropriately. If you want to
> retain the history of "this group of commits did one job" without
> losing the commits themselves, you have to use merges. Otherwise, it's
> one or the other.
> 
> One of the beauties of git is that it allows myriad workflows. One of
> the great difficulties of getting started with git is that it allows
> myriad workflows. The curse of choice, multiplied out. :)

   (-:

> ChrisA

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