[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ptp-dev] Merge policy reminder
|
Hi Doug,
On Fri, Feb 10, 2012 at 1:42 PM, Doug Schaefer
<cdtdoug@xxxxxxxxx> wrote:
I haven't been following this conversation too closely, but I remember someone dismissing the use of cherry picking. That actually seems to be what everyone else is doing. Commit your change to ptp_5-0 then cherry pick it over to master. Just a thought.
I would be very interested to hear, why CDT is using cherry-pick ( I can't find any discussion of the pro/cons on the cdt mailing list or the original git conversion bug). For all projects I'm aware of (both Eclipse (e.g. Egit) and non-Eclipse projects) CDT is the only one using cherry-pick. So I'm surprised to hear that so many are using cherry-pick.
Roland
Doug.
Clarification: I wasn't saying the policy wasn't good.
I was saying that the wording on the wiki page was not clear.
Please tell us the steps for what we should be doing when we check in files.
To be honest, I didn't know until last week that we are supposed to "do" a merge when we check files in.
I thought we only had to "do" something if there was a conflict where two people changed the same files.
So please tell me if this is correct. To change a file we should, if changing both ptp_5_0 and master branches:
1. In ptp50 workspace, commit to ptp_5-0
2. push to put the change on the remote git repository at
eclipse.org
3. In ptp60(master) workspace, pull then merge? merge then pull?
...Beth
Beth Tibbitts
Eclipse Parallel Tools Platform
http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address: IBM Corp., 745 West New Circle Road, Lexington, KY 40511
Roland
Schulz ---02/10/2012 11:42:33 AM---On Fri, Feb 10, 2012 at 10:34 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote: > I think the procedur
On Fri, Feb 10, 2012 at 10:34 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:
I think the procedure on the wiki needs to clearly state thie in
http://wiki.eclipse.org/PTP/environment_setup/git#Merging
It says "all changes in ptp_5_0 are regularly merged into master" It sounds like this might happen automatically - I'll admit I didn't understand this until recently.
I wrote this because this is how I am used to doing merges on my other projects (and main other project "Gromacs" has similar number of code-lines, commits and contributors). And this always worked fine. Not automatically but without
little problem for the person doing the merge.
Is the merge difficult for PTP?
Greg, do you have some rough estimate of how often you get merge conflicts when doing a merge? And if this number is high, is there some dominant reason for those conflicts? I'm asking because doing the merge for Gromacs is often
conflict free or the conflicts are very easy to resolve even for the person who didn't write the code.
I just looked at the log and I could only find two merges which had conflicts. If that is true I don't understand the problem. That would mean that for the large majority of merges, git was able to do the merge automatically without
the need to resolve any conflict (after someone told git to do the merge). And if that is true I don't understand Greg's originally message.
On the other hand if the log is not correct and there were many merges which had conflicts it would be good to know why the log is incorrect. Also it would be important to make sure that the messages are correct in the future because
I think a SCM system with incorrect log is not good at all.
If we state the procedure clearly on the wiki as the steps to take when you check in something, then it's easier for people to learn how to do.
I can make the steps say
To check into 50 and master: (Two diff workspaces assumed)
1. check in: commit and push to ptp_5_0
2. from master: what order of Team>Merge and Team>Pull??
you want to first pull (or fetch). Because if you don't have the remote tracking branch updated you won't merge in the changes you have done in the different work space.
BTW: I just realized another problem with Egit: For the merge one has to have all the projects, which have a conflict, opened in the workspace (otherwise one can't resolve the conflict within Eclipse). Thus it is probably best if
one has them all and all open.
865-241-1537, ORNL PO BOX 2008 MS6309_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
--
ORNL/UT Center for Molecular Biophysics
cmb.ornl.gov865-241-1537, ORNL PO BOX 2008 MS6309