I want to emphasize Jay's point about creating your branch from the branch it will eventually be merged back into. When your feature or bug will be merged into multiple branches (pulp-2.0 and master perhaps), start your branch from the branch that has the fewest new commits. In this case, start from pulp-2.0 because it does not include some of the commits in master. Merging from pulp-2.0 into master will be easier than the reverse.
For most cases, a good rule of thumb is to branch from the smallest version number you intend to merge your work into. Michael ----- Original Message ----- From: "Jay Dobies" <[email protected]> To: [email protected] Sent: Monday, November 12, 2012 4:29:33 PM Subject: [Pulp-list] 2.0 Branched We created the branch in all three repositories called pulp-2.0. From now until the 2.0 release, make sure you understand if what you are working on should be included in both master and this branch. If so, you'll need a pull request for each. For what it's worth, starting with the pulp-2.0 branch as the basis for your feature/bug branch will likely be the easiest when it comes to preventing merge conflicts into the 2.0 release branch. We'll be doing the first 2.0 beta build this afternoon. More info will be sent out when it's available. Ping me with any questions. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
