| Roland,
It sounds like you're advocating for a strategy of committing changes to each branch separately, which is what Chris is suggesting. Is that correct? I'm happy to go that way if you think it provides overall benefits.
Greg -----
Linus recently had this to say about Git:
Q
You released the Git distributed version control system less than ten years ago. Git caught on quickly and seems to be the dominant source code control system, or at least the one people argue about most on Reddit and Hacker News.
Linus
Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd.
Q I thought Subversion was hard to understand. I haven’t wrapped my head around Git yet.
Linus:
You’ll spend a lot of time trying to get your head around it, and being ridiculed by the experts on github and elsewhere. I’ve learned that no toolchain can be too complicated because the drive for prestige and job security is too strong. Eventually you’ll discover the Easter egg in Git: all meaningful operations can be expressed in terms of the rebase command. Once you figure that out it all makes sense. I thought the joke would be obvious: rebase, freebase, as in what was Linus smoking? But programmers are an earnest and humorless crowd and the gag was largely lost on them.
On Sep 28, 2012, at 12:09 PM, Roland Schulz 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.gov865-241-1537, ORNL PO BOX 2008 MS6309
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
|
