Le 08/01/2015 16:42, Gilles a écrit : > On Thu, 8 Jan 2015 10:24:49 -0500, Gary Gregory wrote: >> On Thu, Jan 8, 2015 at 9:24 AM, Luc Maisonobe <l...@spaceroots.org> wrote: >> >>> Le 08/01/2015 07:59, Thomas Neidhart a écrit : >>> > On 01/08/2015 02:40 AM, Phil Steitz wrote: >>> >> >>> >> >>> >> >>> >> >>> >>> On Jan 6, 2015, at 3:10 PM, Gilles <gil...@harfang.homelinux.org> >>> wrote: >>> >>> >>> >>> Hi. >>> >>> >>> >>> Do we head towards 4.0, starting to implement the dreaded >>> >>> breakings? ;-) >>> >> >>> >> How about starting a new 4.0 branch and keeping head set up for >>> 3.x so >>> we can cut 3.4.1 when the bugs start coming in against 3.4. >>> > >>> > +1 >>> >>> Of course a branch is needed, but why consider master should be 3.x and >>> 4.0 should be a side branch. >>> >>> If we consider 4.0 is the future and 3.x is only for bug fixes, then 4.0 >>> should be master and 3.x a side branch. This side branch could be >>> created later on, if needed. It is straightforward to create new >>> branches in git even from very old commits, so the branch creation can >>> be delayed until needed (and only if needed). > > What would happen if we then need to merge (backport) a modification > performed under the "o.a.c.math4" hierarchy into the "o.a.c.math3" > hierarchy of that branch? > Would two files "o/a/c/math4/SomeAlgo.java" and "o/a/c/math3/SomeAlgo.java" > be considered the same w.r.t. to "diff"? Or would we need to manually copy > from "math4"?
Git knows about renaming files, so an attempt to do a direct merge (or a git cherry-pick) would lead to a conflict being detected (file moved in one branch and file change in another branch). I just did a small test for it. So we would need to do a "git diff -p" to create a patch, use a "sed" command or equivalent to replace the package name, and "git apply" to apply it. In any case, this would be the exact same situation if 4.0 were a side branch and 3.x master. best regards, Luc > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
