Hi. FYI, Spring Data Redis used your approach now, so we can take a look. https://github.com/spring-projects/spring-data-redis
At first, I like your approach. Major point is that commit's changeset size will be completely relied on JIRA issue's size, and we can have another pain point when changeset becomes huge. I sought some of merged PRs from Storm repo, and their changesets seems small enough to leave just one commit per PR. Additional point is how we leave multiple commits' log messages into one. Headline of log can contain useful information which describes code change, and applying this approach improperly we can lose them. Furthermore, we're also having huge PR. (for example, STORM-561 <https://github.com/apache/storm/pull/546>) I wonder we can apply same approach to this, or go with exception. Btw, real pain point from cherry-picking is conflicts. Jedis uses same approach, and we have to believe collaborators and unit tests, and we did some mistakes while cherry-picking and unit tests couldn't catch it. It would be not resolved though we squash commits into one. Have to make cherry-picking branch and post a PR related to merging cherry-picked branch into specific version? Sincerely, Jungtaek Lim (HeartSaVioR) 2015-05-09 6:14 GMT+09:00 Harsha <[email protected]>: > Hi, > Today we are merging into storm master branch using PRs. These PRs > are usually contain multiple commits on different time lines . > There are few issues with this approach , the major pain point is if we > want cherry-pick a single JIRA current approach makes it harder as we have > track down all the commits that went in for a particular JIRA. > I am proposing we should squash these multiple commits into one singe > commit before merging into trunk and associate the STORM JIRA in commit > message. > Let me know what you think. > > Thanks, > Harsha > > > > > -- Name : 임 정택 Blog : http://www.heartsavior.net / http://dev.heartsavior.net Twitter : http://twitter.com/heartsavior LinkedIn : http://www.linkedin.com/in/heartsavior
