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

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

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

That makes sense.

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

Our local workflow allows small commits directly onto master, and these
are in fact rebased to be ff merges.   We also don't allow merge commits
created by "git pull".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20150324/209d2f07/attachment.asc>