Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] ptp_6_0 branch created

This is way too complicated... (Just a comment.. not a Git lover still...  but in my defense, I *did* buy the "Pro Git" book recently and am reading it each night before I fall asleep. If my insomnia is active, I read alot of Git.  If it's not, it puts me to sleep.  a win/win situation.  Author is a very good writer.)

Just wondering ChrisR, does CDT have a git commit policy, and is that what you described?


...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


Inactive hide details for John Eblen ---09/28/2012 02:02:32 PM---Hi Committing manually can cause problems when other developerJohn Eblen ---09/28/2012 02:02:32 PM---Hi Committing manually can cause problems when other developers attempt to


    From:

John Eblen <jeblen@xxxxxxx>

    To:

Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>,

    Date:

09/28/2012 02:02 PM

    Subject:

Re: [ptp-dev] ptp_6_0 branch created

    Sent by:

ptp-dev-bounces@xxxxxxxxxxx




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


        From:
        Greg Watson <g.watson@xxxxxxxxxxxx>
        To:
        Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
        Date:
        09/27/2012 10:01 AM
        Subject:
        [ptp-dev] ptp_6_0 branch created
        Sent by:
        ptp-dev-bounces@xxxxxxxxxxx





        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


        _______________________________________________
        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
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


GIF image

GIF image


Back to the top