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 20:40:43 GMT
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 <> 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 <> 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.

> best regards,
> Luc
>>> Phil
>> Regards,
>> James
>> ---------------------------------------------------------------------
>> 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