On 9/5/15 10:28 AM, Luc Maisonobe wrote: > Le 05/09/2015 01:47, Gilles a écrit : >> On Fri, 04 Sep 2015 19:50:05 +0200, Thomas Neidhart wrote: >>> On 09/04/2015 03:08 PM, Gilles wrote: >>>> Hello. >>>> >>>> There are two branches for Commons Math. >>>> >>>> For one, the top-level Java package is >>>> org.apache.commons.math4 >>>> For the other, it is >>>> org.apache.commons.math3 >>>> >>>> Unless I'm mistaken, this should imply that maven tries to compile >>>> only files under either >>>> src/main/java/org/apache/commons/math4 >>>> src/test/java/org/apache/commons/math4 >>>> or >>>> src/main/java/org/apache/commons/math3 >>>> src/test/java/org/apache/commons/math3 >>>> >>>> But it happens that I have currently files in "math3" not currently >>>> checked in into git: those are new files which git does not remove >>>> when switching branches. >>>> Then when starting a compilation in "master" (where the top-level >>>> is "math4"), lots of compilation errors occur. >>>> >>>> The "source" top-level directories do not seem to be specified >>>> in the project's POM. >>>> Can the parent be changed in order to produce the desired behaviour? >>>> >>>> Or is there a workaround? >>>> Is there a better way to handle the situation (short of manually >>>> moving the source files back and forth)? >>> you probably want to take a loot at the stash command from git. >>> >>> This is very helpful (and needed) when switching between branches. >>> The source files are required to be tracked by git though (i.e. need to >>> be added). >> Yes, I've used it, but perhaps not in the most efficient way (?). >> >> For backporting, I ended up keeping files from "math4" open in an editor. >> Switch branch, and copy/paste code to the corresponding "math3" files. :-} >> >> Suggestion for a better way welcome (as requested a few weeks ago)... > When I port a change from math3 to math4 (or the other way round), what > I do is: > > - do all the work in one version, including git commit > - once a change is committed in one version, I create the > path file for the other version with something like: > > git diff -p HEAD~1 HEAD | sed 's,math3,math4,g' > /tmp/x.patch > > - then I swith to the other version > > git checkout master > > - then I applied the patch that already contains the updated number > > patch -p1 < /tmp/x.patch > > - then I commit it in this branch > > commit -m "the message for the commit' > > It works quite well.
I do the same thing, except that I generate the patch before the first commit, so I don't need the additional arguments to the git diff. Now and then the patches don't apply cleanly, but that's to be expected when refactoring has happened in master. Phil > > best regards, > Luc > >>> afaik, you can also exclude files from the src folder, so that they are >>> not compiled. >> That would be fine too (the "reverse" of Ole's proposal). >> >> >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
