Hi Ravi, Thanks for reviewing. I think the choice between merge and rebase is very situational, so I don't want to be too prescriptive in the text we're voting on. On the wiki page or docs, I'll include more discussion about when one or the other might be preferred.
Responses have been positive thus far, I'll start a real [VOTE] tomorrow unless there are more edits. Best, Andrew On Thu, Aug 20, 2015 at 10:12 AM, Ravi Prakash <ravi...@ymail.com> wrote: > Thanks for the work Andrew! Should we specify a "preference" for one > workflow over another? If not, this looks good. > > > > On Wednesday, August 19, 2015 12:04 PM, Colin McCabe < > cmcc...@alumni.cmu.edu> wrote: > > > +1. Rebasing can really make the history much clearer when used > correctly. > > Colin > > On Tue, Aug 18, 2015 at 2:57 PM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > Hi common-dev, > > > > Based on the prior [DISCUSS] thread, I've put together a new [VOTE] > > proposal which modifies the branch development practices edified by the > > [VOTE] when we switched from SVN to git [1]. This new proposal modifies > the > > third and fourth points of the earlier [VOTE], copied here for your > > convenience: > > > > 3. Force-push on feature-branches is allowed. Before pulling in a > feature, > > the feature-branch should be rebased on latest trunk and the changes > > applied to trunk through "git rebase --onto" or "git cherry-pick > > <commit-range>". > > > > 4. Every time a feature branch is rebased on trunk, a tag that identifies > > the state before the rebase needs to be created (e.g. > > tag_feature_JIRA-2454_2014-08-07_rebase). These tags can be deleted once > > the feature is pulled into trunk and the tags are no longer useful. > > > > Said new proposal expands and modifies as follows: > > > > ==== > > > > 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. > > > > ==== > > > > LMK what you think about the above, when we finalize I'll kick off a > > [VOTE]. Last time we did "Adoption of New Codebase" but this feels more > > like "Modifying bylaws," if it needs a [VOTE] at all. "Bylaws" is easier, > > since it's just a lazy majority of active PMC members rather than 2/3rds. > > > > If the eventual [VOTE] passes, I'll put it on the wiki somewhere for > easier > > reference. I'll also expand said wiki page with discussion about merge > vs. > > rebase based on the mailing list threads, since I think we've got some > good > > information here. > > > > Best, > > Andrew > > > > [1]: > > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201408.mbox/%3CCALwhT94Y64M9keY25Ry_QOLUSZQT29tJQ95twsoa8xXrcNTxpQ%40mail.gmail.com%3E > > > >
