[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] ptp_6_0 branch created
|
Hi
Committing manually can cause problems when other developers attempt to merge branches:
1) Duplicate commits will occur in the master history.
2) If commits aren't exactly the same, the other developer has to figure out what should be merged and may have to contact the
other developer if it is unclear.
3) Commits meant just for 6.0 will be merged into master automatically (and accidentally).
4) Most importantly, Git does not recognize identical commits across different branches when merging. This can make merges
much more complicated, since it will mix those changes with other changes made in the same region of code.
As Roland points out, there are different possible Git policies. The only downside of our policy is the need to revert commits that
should only be in 6.0. This should happen very rarely, though, and otherwise the policy is pretty straightforward.
John
On Fri, Sep 28, 2012 at 12:09 PM, Roland Schulz
<roland@xxxxxxx> wrote:
Hi,
if one always reverts every change in 6.0 in master (either by "merging and then reverting" or by "merging with strategy ours" (later is dangerous if done incorrectly)) for all changes to 6.0 whether or not they should go into master, then it doesn't mess up things, and also doesn't cause unnecessary merge conflicts. But of course it makes it very inconvient. It still has the problem that it causes double commit messages and unnecessary merge commits in the log. Also it has the disadvantage one can forget to apply patches from 6.0 to master.
If it is done any other way (without reverting every single commit) one can easily mess up and it can easily happen that patches meant for 6.0 go into master or one gets unnecessary merge conflicts between the patch for 6.0 and the one for master.
These problems wouldn't exist if everyone would apply changes to both branches separately only by mixing merge strategies between members of the same team.
Thus it is highly recommended to use the same merge strategy by everyone of one project.
Roland
On Fri, Sep 28, 2012 at 11:29 AM, Greg Watson
<g.watson@xxxxxxxxxxxx> wrote:
Roland,
Do you know if there is any problem doing it this way?
Greg
On Sep 27, 2012, at 10:46 AM, Chris Recoskie wrote:
I tend to apply my changes manually to both branches rather than merging. Is that workflow going to be a problem?
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
<graycol.gif>Greg Watson ---09/27/2012 10:01:50 AM---Hi, I've created a ptp_6_0 branch for the Juno version of PTP. Kepler builds will now come from the
Hi,
I've created a ptp_6_0 branch for the Juno version of PTP. Kepler builds will now come from the master branch.
Please review the documentation[1] for working on multiple branches, but in summary:
- bug fixes that affect both branches should be committed to the ptp_6_0 branch and then merged with master
- bug fixes that are only for ptp_6_0 branch must be committed to the ptp_6_0 branch and merged with master, then reverse the commit in master
- changes only for master can be committed directly to the master branch
Thanks,
Greg
[1] http://wiki.eclipse.org/PTP/environment_setup/git#Committing_and_Merging
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
--
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
