On 12/9/15 12:53 PM, Luc Maisonobe wrote: > Le 09/12/2015 19:22, James Ring a écrit : >> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz <[email protected]> wrote: >>> On 12/9/15 9:13 AM, luc wrote: >>>> Le 2015-12-09 16:49, Phil Steitz a écrit : >>>>>> On Dec 9, 2015, at 8:39 AM, luc <[email protected]> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> The development status for the field-ode branch (linked to issue >>>>>> MATH-1288) >>>>>> is now stable. I will therefore merge this branch into the >>>>>> MATH_3_X branch >>>>>> very soon now. >>>>> What about master? >>>> I may merge all the commits as a single one in master or reproduce >>>> all >>>> commits from the branch one by one. A single big commit will >>>> probably be >>>> more friendly to the list. Separate commits will show the development >>>> steps. >>>> >>>> Also in master, the primitive double API for ode will be changed to >>>> be consistent with the new API developed for field ode. I could not >>>> do that in 3.X because these are publis user-oriented interfaces, so >>>> changing them would introduce a huge incompatibility. >>>> >>>> At the end, this is a new feature, not a modification of an >>>> existing feature, >>>> so I don't know if the steps before the feature is complete are >>>> interesting or not. These steps will be available in the MATH_3_X >>>> branch (and in the field-ode branch), but not in the master branche >>>> if I do a single big commit. >>>> >>>> >>>> What do you prefer? >>> I am not sure. I just wanted to make sure the new feature got into >>> master as well as 3_X. >>> >>> I have been following the branch commits and as long as the record >>> of these granular commits can be traced, I am fine with the single >>> commit to master. If you take the single commit approach to master, >>> will the steps be traceable from master or will we have to go back >>> to 3_X to trace things? If the latter, it would be good to add >>> something to the big commit message to direct later archaeological >>> investigations back to the 3_X branch. > As MATH_3_X and master have forked a few months ago and will never > benn merged back, nothing in master will track back to anything > in MATH_3_X that occurred after the fork. > >>> What is the standard git way >>> of dealing with kind of thing? > The standard way is to use a regular merge, but it doesn't work for us > as per our directories layout change. > >> Just an outsider's perspective, I would expect that people would want >> the branches to be merged without squashing all the commits down into >> one mega commit. It's unfortunate that an email would be generated for >> each one of these, but oh well. ;) > OK, then I think I will try to replay all the commits. It will just be a > few lines scripting with shell and sed. It will mean lots of mail on > the list. The good news will be we can refer back to the tracks at some > time in the future. > > I don't now if I will do it very soon or not, it will depend on > available time and priorities.
Personally, I would rather see your available [math] time spent advancing the code :) Every backward-looking use case I can imagine would be served by an indication in the large master commit that granular history is in the 3_X branch, which is not going away. What you might do is separate out the 4.x-specific refactoring into a separate set of commits. I guess that will happen naturally anyway. Phil > > best regards, > Luc > >>> Phil >> Regards, >> James >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
