> I can't see this problem with the actual merge script, it works very well and > on the git history we will have only one "commit" for issue. The issue is that this "one commit" is very difficult to work with.
My understanding was that Salesforce have their own branch, with private changes. Each time we release, they want to merge the new changes into their private branch. I've had to deal with this kind of relationship between branches and repos before, and in these scenarios, small self contained commits that only do one thing are much better to work with. You have fewer conflicts and when conflicts do occur its clearer what should be done with the conflict. While this may not be a concern for the project now, as we're really only working on master, as adoption grows we could easily see a situation where there's a super stable branch, which we only pull back bugfixes to. Small commits makes this easier. It also facilitates selecting which bugfixes to pull back by looking at the commit log rather than by looking at github/jira (which may not be up to date). In general it makes the commit log much more useful. If you need to bisect a branch to find when a bug was introduced, small commits let you pinpoint the offending change more accurately. Finally, it gives the committer a chance to curate their changes, allowing them to clarify their intent, not only to reviewers, but also to themselves. In short, I don't like big commits :) -Ivan
