On Wednesday, 11 December 2013 at 03:12:40 UTC, Andrew Edwards
wrote:
On 12/10/13, 10:18 AM, Dicebot wrote:
On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro
Lucarella wrote:
I don't understand. Rebasing the release branch on top of
master
shouldn't be an option, as it means you are taking
On Thursday, 12 December 2013 at 15:09:12 UTC, Leandro Lucarella
wrote:
Ah, perfect, then ignore my previous message :)
P.S. I have just made a test rebase to provide better
instructions for Andrew and can confirm that cherry-picked
commits still cause conflicts (as well as any other
same-conte
Dicebot, el 10 de December a las 16:18 me escribiste:
> On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella
> wrote:
> >I don't understand. Rebasing the release branch on top of master
> >shouldn't be an option, as it means you are taking all the changes
> >to
> >master and put them in
On Wednesday, 11 December 2013 at 09:13:05 UTC, David Nadlinger
wrote:
This collection of "anything" includes local tracking branches
people might already use, a simple "git pull" won't work
anymore. Thus, it's very much not just an abstract
inconvenience – it might be trivial to fix, but less
On Tuesday, 10 December 2013 at 13:43:51 UTC, Dicebot wrote:
It is not a problem to reset local branches on rare occasions
like this one, whatever developer count is. Reason why rebasing
of public branches is discouraged is not some abstract
inconvenience of collaboration - it is the fact that
On 12/10/13, 10:18 AM, Dicebot wrote:
On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote:
I don't understand. Rebasing the release branch on top of master
shouldn't be an option, as it means you are taking all the changes to
master and put them in the release branch. That's ju
On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella
wrote:
I don't understand. Rebasing the release branch on top of master
shouldn't be an option, as it means you are taking all the
changes to
master and put them in the release branch. That's just using
master as
a release branch.
Dicebot, el 10 de December a las 14:01 me escribiste:
> On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
> >I which case, updating with master will be counter productive.
> >Thanks for the heads up. I will just have to rely on the devs to
> >cherry-pick what was not originally in
On Tuesday, 10 December 2013 at 13:37:11 UTC, David Nadlinger
wrote:
On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
Can't agree. Release _tags_ are public. Release branches exist
primarily to organize development.
I'm not talking about public in the sense of them being an
artefa
On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
Can't agree. Release _tags_ are public. Release branches exist
primarily to organize development.
I'm not talking about public in the sense of them being an
artefact we want to provide to end-users, but just in the sense
that more t
On Tuesday, 10 December 2013 at 13:25:02 UTC, David Nadlinger
wrote:
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards
wrote:
I which case, updating with master will be counter
productive. Thanks for the heads up. I will ju
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards
wrote:
cherry-picking is discouraged in that scenario as it will
complicate merging 2.065 branch back into master after release.
rebase sounds like best fit.
Or just dro
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards
wrote:
I which case, updating with master will be counter productive.
Thanks for the heads up. I will just have to rely on the devs
to cherry-pick what was not originally in
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards
wrote:
I which case, updating with master will be counter productive.
Thanks for the heads up. I will just have to rely on the devs
to cherry-pick what was not originally included in the branch.
cherry-picking is discouraged in that
On Tuesday, 10 December 2013 at 05:45:26 UTC, Kenji Hara wrote:
On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards
wrote:
2) What is the process to update a branch with all changes
master? I will need to do this because a lot o
On 12/10/13, 12:45 AM, Kenji Hara wrote:
On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
2) What is the process to update a branch with all changes
master? I will need to do this because a lot of changes have occur
On 12/10/13, 2:16 AM, Jacob Carlborg wrote:
On 2013-12-09 16:30, Jacob Carlborg wrote:
Make sure I got GCC, I don't think the test suite passes if DMD built
with Clang.
* you got.
Ok... will do.
On 2013-12-09 16:30, Jacob Carlborg wrote:
Make sure I got GCC, I don't think the test suite passes if DMD built
with Clang.
* you got.
--
/Jacob Carlborg
On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards
wrote:
2) What is the process to update a branch with all changes
master? I will need to do this because a lot of changes have
occurred since the 2.065 branches were created bu
On 12/9/13, 10:36 AM, Dicebot wrote:
Also I don't think you need to bother with maintaining own forks unless
you are planning to actually push something upstream. Just cloning core
repos on build systems should be enough.
At least for the time being, the only things I need to push are
tags/br
On 12/9/13, 10:28 AM, Dicebot wrote:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
I am experiencing a slight problem on Fedora though. After initial
config, I was able to login remotely but now receive the error
"Connection refused". Can't remember changing anything to cause
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
2) What is the process to update a branch with all changes
master? I will need to do this because a lot of changes have
occurred since the 2.065 branches were created but the actual
betas are not yet prepared. Going forward, thi
Also I don't think you need to bother with maintaining own forks
unless you are planning to actually push something upstream. Just
cloning core repos on build systems should be enough.
On 2013-12-09 15:48, Andrew Edwards wrote:
I've prepared a build environment on Mac OS X 10.9 with five VirtualBox
images as follows:
1) Mac OS X 10.9
Make sure I got GCC, I don't think the test suite passes if DMD built
with Clang.
--
/Jacob Carlborg
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
I am experiencing a slight problem on Fedora though. After
initial config, I was able to login remotely but now receive
the error "Connection refused". Can't remember changing
anything to cause this but anything is possible so I
All,
The following lists my progress and few points for which I need
clarification.
I created a git hub account (AndrewEdwards) and obtained necessary
access to all repos at github.com/D-Programming-Language. Access to the
ftp is pending but should be granted shortly.
I've forked the follo
26 matches
Mail list logo
