[math] branch merge to come, prepare for a huge flood of git messages

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[math] branch merge to come, prepare for a huge flood of git messages

Luc Maisonobe-2
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. 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

Phil Steitz


> On Dec 9, 2015, at 8:39 AM, luc <[hidden email]> 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?

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

Luc Maisonobe-2
Le 2015-12-09 16:49, Phil Steitz a écrit :

>> On Dec 9, 2015, at 8:39 AM, luc <[hidden email]> 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?

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

Phil Steitz
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 <[hidden email]> 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?

Phil

>
> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

James Ring
On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz <[hidden email]> 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 <[hidden email]> 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?

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. ;)

> Phil

Regards,
James

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

Luc Maisonobe-2
Le 09/12/2015 19:22, James Ring a écrit :

> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz <[hidden email]> 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 <[hidden email]> 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,
Luc

>
>> Phil
>
> Regards,
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] branch merge to come, prepare for a huge flood of git messages

Phil Steitz
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]