2017-10-06 10:25 GMT+02:00 Ivan Kelly <iv...@apache.org>: > > 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 :) >
I don't like them too. Sometimes it is difficult to split a commit in multiple changes. The "local" git history for an issue is not usually good to be copied to upstream (Apache master) because it would be full of local minor fixes. I think that the best we can do it to always split a commit to minimal components, but actually we are working this way I am struggling with the BP-14 feature because I am trying to split the work but without a good result, the patch impacts: - client side API - zk metadata - wire protocol - journal - LAC protocol it is difficult to have a single commit which makes sense on its own, but it is useful for reviews to have single commits but at the end of the story I image it will be pushed as one or two commits Enrico > > -Ivan >
