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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev