I have to say, having experienced these other pains, I am less unhappy about merge commits than I used to be.
On Wed, Aug 8, 2018 at 11:49 AM Derek Dagit <der...@oath.com.invalid> wrote: > 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 > -- *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
