On Sun, Feb 21, 2010 at 08:44:05PM +0000, Chris Morley wrote:
>
>
>
> > One answer that comes to mind is to remember this, and on the master
> > branch revert the commit after the merge that introduces it.
> >
> > X--o--A--o--o [v2.4_branch]
> > \ \
> > o--o--o--M--A' [master]
> >
> > X represents the place where we branched 2.4, A represents the change
> > to disable incomplete pncconf features, and A' represents the revert of
> > A. (Optionally, squash A' into M so that they're a single commit)
> >
>
> So this is what I did and it worked fine. Thanks.
> next question.
> When 2.4 is merged to master again will I have to do it again?
No, and here's why. After the next merge, the new history will look
like
X--o--A--Y--o--o--Z [v2.4_branch]
\ \ \
o--o--o--M--A'--o--M2 [master]
The common ancestor of v2.4_branch and master is now Y, not X, so git
only considers changes from Y to Z at the next merge, so the problematic
commit A isn't in the list. (git determines this automatically
> Truthfully I don't understand why we merge 2.4 to master.
> Is this a temporary thing, done untill 2.4 is released?
While I'm open to others' opinions about this--as well as the reality of
whether merges generally go smoothly or not--I hope to continue the
practice. Except in rare cases, we want to fix the same bugs in master
as we want to do in v2.4_branch. Unless the specific part of the
software being fixed has changed radically in master, the same bugfix is
likely to be applicable in both places (and when it's not, git almost
always detects this fact, the "merge conflict"). Many git-based
projects have adopted this practice, most notably the git project
itself.
Eventually, v2.4 and master will be so different that merges will
usually fail, instead of usually working (for instance, if the
joints_axes3 branch is merged into master, then any jogging-related
changes in v2.4_branch are unlikely to merge cleanly into master anymore).
When the pain of this gets too great, we'll have to switch strategies
(for example, to cherry pick some fixes and manually rewrite others), or
(after 2.5 is released) abandon v2.4 and no longer make bugfixes there.
Jeff
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
