All that sounds good to me Alan
Regarding the naming - well that is not so important to me as
everything else and it sounds like there are options if we need them.
Phil
On 28 May 2015 at 00:33, Alan W. Irwin wrote:
> On 2015-05-26 22:13+0100 Phil Rosenberg wrote:
>
>> On 24 May 2015 at 23:01, A
On 2015-05-26 22:13+0100 Phil Rosenberg wrote:
> On 24 May 2015 at 23:01, Alan W. Irwin wrote:
>> [...] I just skimmed an interesting paper called "Fighting
>> regressions with git bisect" by Christian Couder which I highly
>> recommend to others here. (You can probably find it with a google
>>
On 24 May 2015 at 23:01, Alan W. Irwin wrote:
> Hi Phil:
>
> This is long, but you have given me lots to respond to. :-)
>
> On 2015-05-24 09:37+0100 Phil Rosenberg wrote:
>
>> Hi Alan and Dave
>>
>> Some specific comments first, then some general ones after.
>>
>>> Fundamentally, the git world i
Hi Phil:
This is long, but you have given me lots to respond to. :-)
On 2015-05-24 09:37+0100 Phil Rosenberg wrote:
> Hi Alan and Dave
>
> Some specific comments first, then some general ones after.
>
>> Fundamentally, the git world is split on the rebase-only
>> versus merge-only question
> As
Hi, Phil,
On May 24, 2015, at 1:37 AM, Phil Rosenberg wrote:
> I'm not sure this is right, but I would assume that if we apply a bug
> fix to the v5 branch then create a patch of this commit and apply that
> to the v6 branch then if we ever merge (or rebase) the branches then
> git is clever enou
On May 23, 2015, at 1:14 PM, Alan W. Irwin wrote:
> I think we just have to agree to disagree on this issue.
I agree! :-)
> Fundamentally, the git world is split on the rebase-only
> versus merge-only question, and we just happen to fall in different
> camps.
To be honest, this prompte
Hi Alan and Dave
Some specific comments first, then some general ones after.
>Fundamentally, the git world is split on the rebase-only
>versus merge-only question
As it happens I fall in the merge camp. But for the work we have been
doing up to now I don't feel there has been much difference eith
Hi Dave:
I already made my points about continuing with the present workflow
for quite a while longer if not indefinitely in my original post
starting this topic so I think we just have to agree to disagree on
this issue. Fundamentally, the git world is split on the rebase-only
versus merge-only
On 2015-05-23 09:23+0100 Phil Rosenberg wrote:
> Hi Alan
> My initial thought was as yours. To have a separate plplot6 branch.
I have a feeling that with so many of us it might be difficult to keep
track of sending patches round. Do you know how that would work with
clashes? I.e if two people sen
Hi, Phil et al.,
On May 23, 2015, at 1:23 AM, Phil Rosenberg wrote:
> I could make one last alternative suggestion. We could have a private git
> site. This could have separate 5.8 and 6 branches. Then when we are ready to
> merge we can rebase the branch, push it to our sf repo and close the s
o set it up for access for everyone.
Phil
-Original Message-
From: "Alan W. Irwin"
Sent: 23/05/2015 00:27
To: "PLplot development list"
Subject: [Plplot-devel] PLplot 6 and git
Assuming we move forward with plplot6 development in the short term
(either with or without
Assuming we move forward with plplot6 development in the short term
(either with or without moving to C++ for the core library depending
on what the consensus is here on that topic), then we should also
start thinking about the git workflow implications of such a large and
important development top
12 matches
Mail list logo
