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

[Greg Troxel]

I'm not really active, but my $0.02:

1) +1 on proposed changes not being in the official repo

2) if a branch is no longer useful, you might as well just delete it.
Especially if it's a branch that rule 1 says wouldn't have been there.

3) I don't see the need to make an attic.

4) If a branch associated with a ticket needs redoing because other
stuff changed, then definitely do not close/open a new ticket.  The
ticket was about a problem, and that remains.  Making a new ticket
because of an interation of a proposed fix is the tail wagging the dog.
All that's need to avoid force-push confusion is to have a second branch
name under the ticket.

(I see now that you are using "PR" to refer to "pull request".  This is
confusing because people who learned to program before github know that
it means "problem report", and we try to avoid using git-specific terms
to refer to more generic software-engineering workflow issues. :-)

5) Agreed on not force-pushing replacement branches.  In my group we use
.rb1 for the first rebase and so no.  We delete the old one when the new
one arrives.  This is basically like a force push logically except that
it isn't.  The branches are basically cleaned up with fixup commits and
also rebased onto current master, so that they apply cleanly.

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.


-------------- 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/20150321/94d6c707/attachment.asc>