On Fri, Aug 21, 2015 at 1:44 PM, Andrew Wang <andrew.w...@cloudera.com> wrote:
> Hi common-dev, > > As promised, here is an official vote thread. Let's run it for the standard > 7 days, closing on Aug 28th at noon. Only PMC members have binding votes, > but of course everyone's input is welcomed. > > If the vote passes, I'll put the text on the website somewhere as > recommended by Steve. > > Previous discussion threads: > > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2bPWeV2Hk%2B67%3DDamWpVfLTM6nkjb_wG3n4%3DWAN890zqfA%40mail.gmail.com%3E > > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2aDXujQjwdmadVtg2-qrPAJeOgCS2_NHydv8jke8or1UA%40mail.gmail.com%3E > > Proposal: > > ==== > > Feature branch development can use either a merge or rebase workflow, as > decided by contributors working on the branch. > > When using a rebase workflow, the feature branch is periodically rebased on > trunk via "git rebase trunk" and force pushed. > > Before performing a force-push, a tag should be created of the current > feature branch HEAD to preserve history. The tag should identify the > feature and date of most recent commit, e.g. > "tag_feature_HDFS-7285_2015-08-11". It can also be convenient to use a > temporary branch to review rebase conflict resolution before force-pushing > the main feature branch, e.g. HDFS-7285-rebase. Temporary branches should > be deleted after they are force-pushed over the feature branch. > > Developers are allowed to squash and reorder commits to make rebasing > easier. Use this judiciously. When squashing, please maintain the original > commit messages in the squashed commit message to preserve history. > > When using a merge workflow, changes are periodically integrated from trunk > to the branch via "git merge trunk". > > Merge conflict resolution can be reviewed by posting the diff of the merge > commit. > > For both rebase and merge workflows, integration of the branch into trunk > should happen via "git merge --no-ff". "--no-ff" is important since it > generates a merge commit even if the branch applies cleanly on top of > trunk. This clearly denotes the set of commits that were made on the > branch, and makes it easier to revert the branch if necessary. > > "git merge --no-ff" is also the preferred way of integrating a feature > branch to other branches, e.g. branch-2. > I know this is a different topic than the main reason for this vote, but has there been a discussion of using a squashed merge as opposed to a normal merge when feature branches merge to trunk? Squash merges have some advantages including complicating the branch tree. > > ==== > > Thanks, > Andrew >
