Re: [sage-support] Development process

2016-12-08 Thread Dima Pasechnik
On Thursday, December 8, 2016 at 9:22:19 PM UTC, Volker Braun wrote: > > In the current release process I never rebase tickets, fyi. Generally, its > a bad idea to rebase published branches (unless you hate your > collaborators). > on the other hand, reviewers won't hate you as much if you do

Re: [sage-support] Development process

2016-12-08 Thread Dima Pasechnik
On Thursday, December 8, 2016 at 10:45:30 AM UTC, Dima Pasechnik wrote: > > I also do not see why the released tree should not be rebased. After all, > it is merely cleaning after yourself; looks like a good idea. > moreover, as far as we talk specifically about developing Sage library, what

Re: [sage-support] Development process

2016-12-08 Thread Dima Pasechnik
I don't understand how the worktree procedure you describe reduces recompilation in merge/. (although combining this with the merge way I advocate looks like a good idea) I also do not see why the released tree should not be rebased. After all, it is merely cleaning after yourself; looks like

Re: [sage-support] Development process

2016-12-07 Thread Daniel Krenn
On 2016-12-07 10:00, Dima Pasechnik wrote: > I don't see how using git worktree would reduce recompilation, for the > merging workflow you recommend touches a lot of files, potentially. In your SageMath root, assuming you are at branch develop: git worktree add ../merge cd ../merge git trac

Re: [sage-support] Development process

2016-12-07 Thread Dima Pasechnik
I don't see how using git worktree would reduce recompilation, for the merging workflow you recommend touches a lot of files, potentially. The workflow I recommend may be paired with git rebase to get rid of extra commits, leaving a nicer history. -- You received this message because you

Re: [sage-support] Development process

2016-12-07 Thread Daniel Krenn
On 2016-12-07 08:58, Dima Pasechnik wrote: > For the purposes of reviewing you do not care about history being > clean in your local branches, and what I describe does not lead to > much recompilation. For reviewing (without any new commits) this works. > Whereas in particular with old tickets,

Re: [sage-support] Development process

2016-12-06 Thread Dima Pasechnik
For the purposes of reviewing you do not care about history being clean in your local branches, and what I describe does not lead to much recompilation. Whereas in particular with old tickets, with branches based on old versions of Sage, in your approach sometimes one would need to rebuild

Re: [sage-support] Development process

2016-12-06 Thread Daniel Krenn
On 2016-12-06 22:02, Justin C. Walker wrote: > I am starting in a new, empty directory, and 'git' seems to want a repository > specified. > > I have a "global" .gitconfig file set up. > > A couple of questions: > > Should I check out the 'develop' branch first, and then incorporate (how?) >

Re: [sage-support] Development process

2016-12-06 Thread William Stein
On Tue, Dec 6, 2016 at 1:02 PM, Justin C. Walker wrote: > Hi, all, > > I have not done any real Sage development for a while (the last time, I > think, there were wolves in Wales). > Same... and equally interested in the answer :-) > > I want to work on an existing Trac

[sage-support] Development process

2016-12-06 Thread Justin C. Walker
Hi, all, I have not done any real Sage development for a while (the last time, I think, there were wolves in Wales). I want to work on an existing Trac ticket, and I'm not clear on how to start this work. The ticket page gives me a branch (u/blah/branch-name). I am starting in a new, empty