Just FYI, IF we went with merge comments then I believe github by default lets us give the message in the new commit that it creates—It is the PR title by default I think. With rebase-merge github won't change the commit message I think, but we could require an Issue # to be in commit comments before merging them.
There is a bootstrapping problem with instead using a PR # that would require force-pushing to the request's branch, as the PR # is only generated after the PR is opened and therefore a commit message is already there. So to avoid THAT, we could require an Issue for every PR (or commit) as suggested by Alan. "No orphan commits without parent Issues." I think it used to be the case that "merge commits" was the only option available in github, and the other alternatives were added later. Maybe that would explain why the UI is not as friendly about the alternatives. >From the one perspective of solving the original challenges Leif points out, merge commits are attractive as the commit IDs do not change and can be easily tracked across branches and forks. But there is more to the story. I agree merge commits can cause other confusion, and I have seen other projects that really dislike them—There is a reason github supports other ways to merge! I'll deal with a considerable amount of "tedious" bookkeeping work—it is most important to me to do what the community buys into. I have no objection to Leif's original proposal. I am less enthusiastic about using merge commits mixed with rebase-merge, but if it makes managing releases easier I'll go with that too. On Wed, Aug 8, 2018 at 9:23 AM, Alan Carroll < solidwallofc...@oath.com.invalid> wrote: > Another approach might be to use issues more, to substitute for JIRA > tickets. E.g. every PR has an issue and the commits are labeled with that > issue #. That would give us a key string to search for in the commit > messages and handle the case (which merge commits don't) where a later > commit is required to fix a prior one. > > On Tue, Aug 7, 2018 at 5:53 PM Jason Kenny <jke...@oath.com.invalid> > wrote: > > > I am just odd... but I search on the commit message. ie the one value in > > the top of the PR page. It has always worked for me.. except when ( which > > we generally don't have) we have a lot of commits with the same message. > In > > these cases, we get a set of commits back and I can check which one I > want > > > > Jason > > > > On Tue, Aug 7, 2018 at 5:04 PM Alan Carroll > > <solidwallofc...@oath.com.invalid> wrote: > > > > > I agree this is ultimately because github has a real problem in their > > user > > > interface, that the knowledge of the destination branch for a merged PR > > are > > > dumped rather than preserved in the PR records. This leaves us with a > > > choice between several (IMHO) unpleasant alternatives - struggling with > > > multi-commit PRs as we do now, only one commit per PR, or merge > commits. > > > Which is the least worst? > > > > > > I'm basically OK with the one commit per PR, except that I've had > simple > > > PRs hang out for a month or so without review or comment, so something > > like > > > #4029 could take half a year to get in, and that's just one piece of a > > > larger work. That's kind of painful. There's also the problem that I > get > > > negative feedback for PRs that don't have an immediate and obvious use. > > > That's problematic if the usage is 2 or 3 PRs in the future, or like > > #4029 > > > where the final commit that ties all the pieces together is 7 commits > > down. > > > > > > Overall, I would tend toward keeping rebase merges for PRs with 1 > commit > > > and using merge commits for multi-commit PRs. The counter argument is > > this > > > is too complex a procedure for our community. > > > > > > > > -- > *Beware the fisherman who's casting out his line in to a dried up > riverbed.* > *Oh don't try to tell him 'cause he won't believe. Throw some bread to the > ducks instead.* > *It's easier that way. *- Genesis : Duke : VI 25-28 > -- Derek
