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.
pgpRkV4hGuCnE.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
