commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] branch merge to come, prepare for a huge flood of git messages
Date Wed, 09 Dec 2015 19:53:32 GMT
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.

best regards,

>> Phil
> Regards,
> James
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message