Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
Thanks Andrew for the proposal! I think a more flexible git workflow will
be very helpful in feature branch development.
I just had an offline discussion with Walter Su, and it happens to be very
relevant to Ravi's question. At least for the EC branch, we find it
problematic to use only 1 approach ("git rebase" or "git merge").
Retrospectively, the optimal approach would have been 1) weekly "git
rebase" to resolve trivial conflicts + 2) occasional "git merge" for trunk
changes that overlaps with many branch commits.
So I agree with Andrew to focus on allowing "git merge" in this [VOTE] and
leave further details (e.g. how to use the 2 options) to each branch's
contributors.
---
Zhe Zhang
On Thu, Aug 20, 2015 at 10:55 AM, Andrew Wang
wrote:
> 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 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
> > 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
> > > ".
> > >
> > > 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 th
Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
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 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 > 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 > > ". > > > > 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 > > > >
Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
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 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 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 > ". > > 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
Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
+1. Rebasing can really make the history much clearer when used correctly. Colin On Tue, Aug 18, 2015 at 2:57 PM, Andrew Wang 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 > ". > > 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
Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
LGTM. This all needs to go into the hadoop docs somewhere too, if/when the vote completes > On 18 Aug 2015, at 14:57, Andrew Wang 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 > ". > > 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
[DISCUSS] Proposal for allowing merge workflows on feature branches
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 ". 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
