Replying to an old thread I realized I'd starred...
On Thu, May 29, 2014 at 6:48 PM, kcrisman wrote:
> Well, I am thankful that my rant led to some pretty substantive discussion.
> Here let me summarize some thoughts.
>
> A) +1 to having something where a github-like editing thing works. I've
>
You don't need to know about that particular subcommand to develop, its
just a bandaid until we have a better build system. There are plenty other
git concepts and subcommands that can definitely be useful in certain
circumstances, but aren't really necessary to work on a ticket.
On Wednesda
On Wednesday, August 27, 2014 8:33:24 AM UTC-4, Volker Braun wrote:
>
> yes it is...
>
But it's not even in http://www.sagemath.org/doc/developer/git_trac.html
Presumably the development of git trac should be pretty tightly connected
to that document. We keep telling people to read it, after
yes it is...
On Wednesday, August 27, 2014 1:26:02 PM UTC+1, kcrisman wrote:
>
> I hope no one minds my resurrecting this, but after having spent a lot of
>> time waiting for Sage to rebuild itself 3 or 4 times, I just discovered
>> this hint, and would like to suggest it make its way onto
>> h
>
> I hope no one minds my resurrecting this, but after having spent a lot of
> time waiting for Sage to rebuild itself 3 or 4 times, I just discovered
> this hint, and would like to suggest it make its way onto
> http://www.sagemath.org/doc/developer/trac.html#section-review-patches,
> and al
I hope no one minds my resurrecting this, but after having spent a lot of
time waiting for Sage to rebuild itself 3 or 4 times, I just discovered
this hint, and would like to suggest it make its way
onto http://www.sagemath.org/doc/developer/trac.html#section-review-patches,
and all other simil
On 2014-05-31, Volker Braun wrote:
> On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote:
>>
>> everything, as for rebuilding docs nothing short of "make distclean &&
>> make" works.
>>
>
> sage -sync-build && sage -b && make doc-clean && make doc
>
> almost always works (there has
On Saturday, May 31, 2014 3:14:41 PM UTC+1, leif wrote:
>
> Did someone meanwhile track down what exactly went wrong / broke
> docbuilding (such that it hangs)?
>
I can't reproduce it, works for me.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" grou
And which part of it being a common assumption among git users that the
first merge commit points back to the branch did you not understand?
On Saturday, May 31, 2014 2:52:15 PM UTC+1, Nathann Cohen wrote:
>
> That's my question from last november :
> https://groups.google.com/d/msg/sage-git/Nok
Volker Braun wrote:
On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote:
everything, as for rebuilding docs nothing short of "make distclean &&
make" works.
sage -sync-build && sage -b && make doc-clean && make doc
almost always works (there has been maybe one case where
By the way I improved this gtmp method since, so that it prepares a
commit message which makes the history clearer (at least to a human)
function gtmp
{
cd ~/sage
git checkout d
rel="$(git log --oneline d ^d~1 | sed s/.*\ //g)"
tn="$(echo "$1" | grep -o "[0-9]*")"
echo "===
> There is nothing wrong with merges
>
> * if you need them
> * if the original branch is the first parent.
>
> Doing it the wrong way makes the history more difficult to understand, and
> we shouldn't teach or facilitate that antipattern.
That's my question from last november :
https://groups.goo
There is nothing wrong with merges
* if you need them
* if the original branch is the first parent.
Doing it the wrong way makes the history more difficult to understand, and
we shouldn't teach or facilitate that antipattern.
On Saturday, May 31, 2014 2:35:30 PM UTC+1, Nathann Cohen wrote:
Yo !
> If you want to edit the ticket branch (that is, add additional
> commits) you cannot use `git trac try`. You must use `git trac
> checkout` to get the actual ticket branch as a starting point.
Why can't you add commits after a merge ? I do this all the time O_o
Nathann
--
You rece
I've implemented a version of this now. From the README:
* Review tickets with minimal recompiling. This assumes that you are
currently on the "develop" branch, that is, the latest beta. Just
checking out an older ticket would most likely reset the Sage tree
to an older version, so you would
On Friday, May 30, 2014 5:11:08 PM UTC+1, kcrisman wrote:
> Right, but the problem is that currently I am uploading it ;-)
Which is exactly why it ought to be difficult to make wrong-way merges in a
branch, so that you can't accidentally/misguidedly upload without
understanding enough of git t
On Saturday, May 31, 2014 1:42:44 AM UTC+1, Dima Pasechnik wrote:
>
> everything, as for rebuilding docs nothing short of "make distclean &&
> make" works.
>
sage -sync-build && sage -b && make doc-clean && make doc
almost always works (there has been maybe one case where it didn't, and
that w
On 2014-05-30, kcrisman wrote:
>
>
> On Friday, May 30, 2014 2:19:24 AM UTC-4, Nathann Cohen wrote:
>>
>> If I understand your complaint correctly, the problem is that
>>> re-compiling after switching branches is too expensive.
>>>
>>
>> You *NEVER* need to recompile everything when switching br
On 2014-05-30, Nathann Cohen wrote:
>
>>
>> If I understand your complaint correctly, the problem is that
>> re-compiling after switching branches is too expensive.
>>
>
> You *NEVER* need to recompile everything when switching branches. There is
> a trick : you should never checkout a branch b
Just got a Github Education account today for my lab, which led me to look
a bit more at their site. This video is relevant:
https://education.github.com/stories#UCBerkeley
> If extra eyes were all that were necessary, there would be no
long-standing mathematical conjectures.
What is needed is bot
>
> Hmm, I was kind of going on the "avoid unnecessary merges" thing.
>>
>
> You can of course do whatever you want on your computer as long as you
> don't upload it...
>
>
Right, but the problem is that currently I am uploading it ;-)
--
You received this message because you are subscribed to
On Friday, May 30, 2014 1:18:43 PM UTC+1, kcrisman wrote:
>
> Hmm, I was kind of going on the "avoid unnecessary merges" thing.
>
You can of course do whatever you want on your computer as long as you
don't upload it...
Also I am scared about merge conflicts, which I do not know how to handle
On Friday, May 30, 2014 2:19:24 AM UTC-4, Nathann Cohen wrote:
>
> If I understand your complaint correctly, the problem is that
>> re-compiling after switching branches is too expensive.
>>
>
> You *NEVER* need to recompile everything when switching branches. There is
> a trick : you should n
>
> If I understand your complaint correctly, the problem is that
> re-compiling after switching branches is too expensive.
>
You *NEVER* need to recompile everything when switching branches. There is
a trick : you should never checkout a branch but instead pull it (merge it)
with your curren
Well, I am thankful that my rant led to some pretty substantive discussion.
Here let me summarize some thoughts.
A) +1 to having something where a github-like editing thing works. I've
used this at least once with matplotlib. My beef with github is orthogonal
to the web interface piece. If
On Thu, May 29, 2014 at 10:29 AM, Travis Scrimshaw wrote:
>I never really have had a problem with the new workflow (in fact, I
> actually prefer it to the old one). However I had a good command of git
> coming into this and read the "git the hard way". So my 2 cents would be to
> have develope
On Thu, May 29, 2014 at 10:37 AM, William Stein wrote:
> On Thu, May 29, 2014 at 10:01 AM, kcrisman wrote:
>> Please excuse the following rant. As usual, it is ill-informed, and if some
>
> I appreciate it, and I'm glad we're having this discussion. (It's a
> rant, but it isn't a flame. Yeah!)
On Thu, May 29, 2014 at 2:22 PM, leif wrote:
> kcrisman wrote:
>>
>>
>> Git workflow.
>>
>> The goal was to reduce work for some developers and make things more
>> modular, but in fact what happens is that people are basing their
>> "branches" on all kinds of different starting points, forcing co
kcrisman wrote:
Git workflow.
The goal was to reduce work for some developers and make things more
modular, but in fact what happens is that people are basing their
"branches" on all kinds of different starting points, forcing constant
recompilation for even the most trivial changes. [...]
Robert Bradshaw wrote:
[...] now that we're on git a pull request is 99% of what a ticket is
I'm happy that this (still) is *not* the case (for most tickets at least).
(specifically, an annotated point to a particular git branch/commit
that needs review) and we should seriously consider accep
On 29 May 2014 20:50, Volker Braun wrote:
> On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote:
>>
>> Can someone point me to instructions for how to install (and use) "git
>> trac"?
>
>
> The developer guide on a sufficiently recent (6.2+) Sage version.
>
> On a related note, the docs
On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote:
>
> Can someone point me to instructions for how to install (and use) "git
> trac"?
The developer guide on a sufficiently recent (6.2+) Sage version.
On a related note, the docs on the web page are still from 6.1.1
--
You rece
On 2014-05-29, John Cremona wrote:
> On 29 May 2014 20:22, Simon King wrote:
>> Hi Volker,
>>
>> On 2014-05-29, Volker Braun wrote:
>>> code: How can I easily find that discussion?
>>>
>>> Pretty easy, I would say: "git trac find ".
>>
>> Wow! That is in fact very useful. Didn't know about
On 29 May 2014 20:22, Simon King wrote:
> Hi Volker,
>
> On 2014-05-29, Volker Braun wrote:
>> code: How can I easily find that discussion?
>>>
>>
>> Pretty easy, I would say: "git trac find ".
>
> Wow! That is in fact very useful. Didn't know about this. So far, I was
> mainly using the dev scri
Hi Volker,
On 2014-05-29, Volker Braun wrote:
> code: How can I easily find that discussion?
>>
>
> Pretty easy, I would say: "git trac find ".
Wow! That is in fact very useful. Didn't know about this. So far, I was
mainly using the dev scripts, and "git trac" only once, I think.
Cheers,
Simon
On Thursday, May 29, 2014 7:26:35 PM UTC+1, Simon King wrote:
>
> Before switching to git, we had the policy (enforced by commit hooks, if
> I recall correctly) that the commit message mentions the ticket number.
No, that was Jeroen manually (ok, with a script) telling you
days/weeks/months lat
Hi Volker,
On 2014-05-29, Volker Braun wrote:
>> : where that is, one cannot learn easily from git log, since
>> $ git log | grep maxima | less
>> $ git log | grep Maxima | less
>>
>
> The git log is not a plain text file, its a directed acyclic graph. There
> is much more useful information in
On Thursday, May 29, 2014 7:00:52 PM UTC+1, William wrote:
>
> The argument that mailing patches "doesn't work at that scale" isn't
> convincing, since Linux kernel development is much bigger than Sage
> development, and they mail patches around
That is not really true. They do mail patches aro
On Thu, May 29, 2014 at 10:49 AM, Volker Braun wrote:
> On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote:
>>
>> As another example, in attempting to review one patch which relies upon
>> the new Maxima update
>
>
> The git branch contains the entire code, so automatically has all
> requi
On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote:
> As another example, in attempting to review one patch which relies upon
> the new Maxima update
>
The git branch contains the entire code, so automatically has all
requirements. You don't need to know where the maxima update comes fr
On Thu, May 29, 2014 at 10:01 AM, kcrisman wrote:
> Please excuse the following rant. As usual, it is ill-informed, and if some
I appreciate it, and I'm glad we're having this discussion. (It's a
rant, but it isn't a flame. Yeah!)
> of the points are due to ignorance, I have no problem with th
I never really have had a problem with the new workflow (in fact, I
actually prefer it to the old one). However I had a good command of git
coming into this and read the "git the hard way". So my 2 cents would be to
have developers spend time learning git properly instead of using the dev
sc
Please excuse the following rant. As usual, it is ill-informed, and if
some of the points are due to ignorance, I have no problem with that being
pointed out. But from reading the lists, I'm not the only one experiencing
difficulty with this sort of thing. At the very least I think it shows
On Thu, May 29, 2014 at 8:49 AM, kcrisman wrote:
> Hi! Thanks again for your thoughtful comments. I see two different issues
> arising in this thread.
>
> 1) Your desire to have a MOOC teaching Python programming around some
> mathematics, which might end up contributing to Sage. (Or sympy, or
Hi! Thanks again for your thoughtful comments. I see two different issues
arising in this thread.
1) Your desire to have a MOOC teaching Python programming around some
mathematics, which might end up contributing to Sage. (Or sympy, or numpy,
or Gambit, or ...) That sounds awesome.
I thi
Thanks for the thoughtful replies. It's a fine line between being critical
of the idea and dismissive of the students. Please everyone limit
yourselves to criticizing the idea, as students might come to this thread
later.
I don't think one should dismiss the students. Look at the Mathworks
competit
On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote:
>
> Again, in the big wave of emails, this one also got misdirected:
>
> Hi everyone,
>
> I am looking for people who want to help me, in one way or another, bring
> hundreds of new first time contributors to sage. If I do
47 matches
Mail list logo
