>
> 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
I had hoped it was smart like that ! great
>
> > 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.
What is the advantage of merging over cherry picking other then
cherry picking requires more intervention?
Who will decide when it will be merged (I would assume you)?
and by what criteria?
I just can't get my head around the advantage of putting fixes in
2.4 then eventually into master. It would seem to better to put
fixes in master let some people use them then put them in 2.4.
unless of course it is something obvious (eg typo) or something
that just belongs in 2.4, in which case you don't want to merge
it to master anyways.
for instance there is the commit you added to 2.4 that allows
python users to know the kernel version needed for realtime.
I need that in master to add the tests I added to 2.4.
now I think I could cherry pick the kernel version commit
and the tests into master now or wait till 2.4 is merged in master.
Probably my biggest problem is I am not fluent in git.
I know enough to do my everyday stuff and read your cheat
sheets when I need to do something unusual (to me).
Anyways thanks for explaining. I will keep my mind open and
see what happens.
Chris M
_________________________________________________________________
Check your Hotmail from your phone.
http://go.microsoft.com/?linkid=9708121------------------------------------------------------------------------------
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
