github branch workflow: moving old branches to an "attic"

[Brian Warner]

On 3/21/15 5:01 PM, Greg Troxel wrote:

> 4) If a branch associated with a ticket needs redoing because other
> stuff changed, then definitely do not close/open a new ticket.
> 
> (I see now that you are using "PR" to refer to "pull request".)

Ah, right, sorry. We keep a single ticket/Problem-Report open for any
given issue. We'll use multiple (sequential) Pull Requests for the
branches.

In addition, I've been in the habit of locally rebasing people's
pull-requests, merging, then manually marking the pull-request as closed
(since github correctly doesn't do that automatically when the patches
have beeen rebased).

> 6) You didn't address this, but when we merge branches, we use an
> explict merge commit, always, even if the branch would be mergeable
> ff. This is to make the history clear, and to have a place to put the
> 'Fixes ticket:NNNN' message.

That's a good point. I've been (inconsistently) putting the "fixes NN"
message in (one of) the pull-request's comments. It'd be better to leave
them out of those comments entirely, and have the merge-commit say it.
This also leaves responsibility for deciding *whether* the branch
actually fixes the ticket (or not) up to the merger, who's a
core-committer and should probably be the one to make that decision
anyways.

I guess I'm neutral on using --no-fast-forward on single-patch fixes. If
they're small enough, I'm happy to skip the merge. But I could be talked
into doing it that way.

thanks,
 -Brian