Note: in my responses I'm mostly thinking of the repositories I have to deal with the most (chromium-crosswalk, v8-crosswalk and crosswalk), your mileage may vary for other repositories.
"Zhang, Zhiqiang" <zhiqiang.zh...@intel.com> writes: > I just tired it at > > https://github.com/w3c/web-platform-tests/pull/2834 > >> What would the commit message look like (by default, a concatenation of all >> commit messages)? How could we determine the pull request a change >> came from (the number is included in the commit title)? > > Comparing the squashed commit (automatically generated by default) to > the commits in the pull request, yes, the pull request number is > included in the commit title. > > The commit message will simply use the title of the pull request + > (pull request number) as its title, and lists all commits' titles as > the unordered items as its body. See > > https://github.com/w3c/web-platform-tests/commit/2bd72173f4580563f51eaadd6c430465be4183be Those were rhetorical questions which I answered myself above :-) >> And if I were to choose between squashing or merging, I would stay with >> merging: >> - I really like it that GitHub can use git better than Rietveld (which >> was conceived at a time when git was not so widespread) including >> allowing separate commits for things that should be committed >> separately (like the PR I mentioned above). Squashing inevitably >> creates one big patch with everything. > > Actually GitHub supports both the two. It is up to you, repository > admin, to use one of squashing or merging, or both. Yes, that's why I said we should settle on one method or another before (per repository or once for the entire organization). >> - This is a problem more specific to our own workflow: it puts a higher >> burden on the person clicking the green button on the pull request >> page to squash the commits because they need to choose the final >> commit message. By default it's going to consist of all the commit >> messages concatenated, meaning that we will end up with commit >> messages saying "fix previous mistake", "now fix it for real" etc >> unless the person merging the PR takes the time to either write their >> own commit message, or copy-paste the pull request message etc. > > Yes, this is a little problem. The person needs to take more time to > make the final commit message. But it is also a good chance for the > person to polish the commit message before confirm the squashing > merge. I'd be fine with that if the person who submitted the pull request was the one merging it, but most of the times this is not the case -- in fact, I'm the one who's been merging most pull requests in the crosswalk repository lately, and I wouldn't like to have to write the commit message myself in addition to spending a lot of time reviewing code. > Actually I am only concerned that we may lose related JIRA issue > information in the final commit message. Say, a request pull only > added BUG=XWALK-N to the PR description, but not in any title of the > commits. The commit message won't include that information; thus > cannot find JIRA issue in 'git log'. Any impact on your JIRA-PR > linking system? It won't impact the GitHub-JIRA system we have in place since it only looks at the pull request message, but as you've rightfully pointed out the squashed commit message will by default get rid of any longer explanations in the commits being squashed, including issue numbers. _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
