commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] branch merge to come, prepare for a huge flood of git messages
Date Wed, 09 Dec 2015 17:45:05 GMT
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 <> 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.  What is the standard git way
of dealing with kind of thing?

> best regards,
> Luc
>> Phil
>>> Unfortunately, our git/mail integration resends the mails
>>> corresponding to all the individual commits performed on a
>>> branch when it
>>> is merged into another branch. So the merge will probably
>>> generate a huge
>>> flood of mails to the list, corresponding to all the work done
>>> on the
>>> field-ode branch since last month.
>>> I apologize for this flood.
>>> best regards,
>>> Luc
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message