Hello John !
> ...ah, and to emphasize: in the old system, this simply wouldn't have
> happened. I would have applied the patch, and only the things that needed
> recompilation would have recompiled. Sometimes, as in this case, that
would
> be an empty set. In the old days, I only recompiled Sage
I agree with Travis.
You declared that "unnecessary merges are bad" and from that line we
find ourselves with bigger problems, i.e. those that are faced by the
beginners when they first review a ticket or write one.
When doing a review the merge is unimportant as it will never be pused
to the bra
>
>
> Really that is Travis' fault for doing an unnecessary merge. Which, in
> turn, forced you to recompile to follow the merge.
>
So instead I have to let my Sage recompile just because I want to work
on a ticket not currently based on the latest development? In fact, I'm
worried I might
On Sunday, November 16, 2014 9:59:34 PM UTC+1, Volker Braun wrote:
>
> On Sunday, November 16, 2014 8:50:41 PM UTC, john_perry_usm wrote:
>>
>> I get that (Travis mentioned it himself), but I'm not sure why it's
>> Travis' fault. First, the only change that needed to be made was a few
>> lines of
> You can still do that, "git show " is just a patch that you can
> apply by hand. Its going to be just as manual labor intensive and error
> prone as before, of course.
>
I don't recall finding it manual labor intensive, and for a while I was
doing quite a bit w/Nathann on MILP. As I recall
Incidentally it is totally archaic and unnecessary that one should have to
do make or "sage -b" at all after changing pure python code. That's purely
a technically problem that we should have solved long ago. Mike Hansen
even implemented something much better once but it didn't get positive
revie
On Friday, November 14, 2014 6:05:02 AM UTC-6, mmarco wrote:
>
>
> So, about the code of conduct, it sounds like a nice set of guidelines.
> But, do we really need it? I mean, has it been some hard conflict that i
> have not been aware of? I know that we have some trolling and flaming going
> o
On Sunday, November 16, 2014 8:50:41 PM UTC, john_perry_usm wrote:
>
> I get that (Travis mentioned it himself), but I'm not sure why it's
> Travis' fault. First, the only change that needed to be made was a few
> lines of Python code. If we could download & test patches as before, this
> wouldn
On Sunday, November 16, 2014 8:08:36 PM UTC+1, Volker Braun wrote:
>
> On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote:
>>
>> This may be because I downloaded a binary, but I don't think so. Even if
>> so, it doesn't make sense: I only changed a few lines a Python code.
>>
>
> I
Le dimanche 16 novembre 2014 19:31:25 UTC+1, Volker Braun a écrit :
>
> On Sunday, November 16, 2014 6:02:22 PM UTC, Eric Gourgoulhon wrote:
>>
>> Can you please tell what the command "git trac try 12345" does, in terms
>> of plain git ?
>>
>
> It just does the merge in a detached head (HEAD is
On Sunday, November 16, 2014 7:20:38 PM UTC, Anne Schilling wrote:
>
> so that I could review the tickets simultaneously. How else would you
> handle this situation?
>
As long as both branches are close enough so that "sage -br" works (no make
required) I don't think thats an issue.
If they are
On Sunday, November 16, 2014 11:08:36 AM UTC-8, Volker Braun wrote:
>
> On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote:
>>
>> This may be because I downloaded a binary, but I don't think so. Even if
>> so, it doesn't make sense: I only changed a few lines a Python code.
>>
>
>
On Sunday, November 16, 2014 6:53:43 PM UTC, john_perry_usm wrote:
>
> This may be because I downloaded a binary, but I don't think so. Even if
> so, it doesn't make sense: I only changed a few lines a Python code.
>
I can think of lots of reasons how unpacking the binary tarball (and the
reloca
...ah, and to emphasize: in the old system, this simply wouldn't have
happened. I would have applied the patch, and only the things that needed
recompilation would have recompiled. Sometimes, as in this case, that would
be an empty set. In the old days, I only recompiled Sage when I completely
On Sunday, November 16, 2014 5:52:16 AM UTC+1, Nathann Cohen wrote:
> Hello everybody !
>
> ...
> Just wondered if we could not have some "git hook" (I do not exactly
> know what it can do) to make sure that one cannot checkout a branch
> which is not a descendent of the latest release of Sage
On Saturday, November 15, 2014 11:37:50 PM UTC+1, Anne Schilling wrote:
>
> On 11/15/14 11:47 AM, mmarco wrote:
> > I am afraid i would need more information to make a decission about
> this. I wasn't aware of the existence of the problems you mention. Without
> knowing what happened in those ca
On Sunday, November 16, 2014 6:02:22 PM UTC, Eric Gourgoulhon wrote:
>
> Can you please tell what the command "git trac try 12345" does, in terms
> of plain git ?
>
It just does the merge in a detached head (HEAD is no longer a named
branch, so you can't push it accidentally)
git checkout --det
I agree: one shall unvoid unnecessary merges.
Can you please tell what the command "git trac try 12345" does, in terms of
plain git ?
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails fr
>> For beginners it is easier
>
> Ok, everybody who is using git and discourages unnecessary merges is just
> stupid and hasn't realized it yet. Possible, but unlikely reason.
I don't know, man I am just telling you that we could advise
beginners to do that because it is easier for
On Sunday, November 16, 2014 5:47:05 PM UTC, Nathann Cohen wrote:
>
> > If you want to argue in favor of unnecessary merges then please also
> provide
> > a reason why other git-using projects are wrong when they discourage
> > unnecessary merges.
>
> For beginners it is easier
>
Ok, everybody wh
Yo !
> A) this will change time stamps and hence cause a lengthy compilation
> anyways
Nono, it only change the timestamps of the files which are modified by the
branch. I am using a small bash script that does that for me since I use
git in Sage and never had this problem anymore.
> B) there is
A) this will change time stamps and hence cause a lengthy compilation
anyways
B) there is a very real cost in unnecessary merges, they make the log
harder to read.
If you want to argue in favor of unnecessary merges then please also
provide a reason why other git-using projects are wrong when
Hi,
Maybe the instruction
git checkout -b my_branch FETCH_HEAD
in the developer's guide at
http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets
should be replaced by
git checkout -b my_branch
git merge FETCH_HEAD
In this way, the trac branch is merged into the user one. If t
On Sun, Nov 16, 2014 at 4:08 PM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> 2014-11-16 5:42 UTC−07:00, Fredrik Johansson :
>>
>>
>> On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote:
>>>
>>> Hello,
>>>
>>> We currently have two much implementation of 2x2 matrices. I found
2014-11-16 5:42 UTC−07:00, Fredrik Johansson :
>
>
> On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote:
>>
>> Hello,
>>
>> We currently have two much implementation of 2x2 matrices. I found at
>> least three that leads to distinct element classes
>>
>> sage: M1 = SL2Z
>> sage: M2 = M
On Sunday, November 16, 2014 5:45:01 AM UTC+1, vdelecroix wrote:
>
> Hello,
>
> We currently have two much implementation of 2x2 matrices. I found at
> least three that leads to distinct element classes
>
> sage: M1 = SL2Z
> sage: M2 = MatrixSpace(ZZ,2)
> sage: from sage.matrix.matrix_intege
> There is "git trac try 12345" which basically does that. It also switches to
> a detached head to minimize the danger of pushing unnecessary merges back to
> trac.
H O_o
And do newcomers still make the mistake ? Or do they run different
commands and end up having to recompile everything ?
There is "git trac try 12345" which basically does that. It also switches
to a detached head to minimize the danger of pushing unnecessary merges
back to trac.
On Sunday, November 16, 2014 4:52:16 AM UTC, Nathann Cohen wrote:
>
> Hello everybody !
>
> On 16 November 2014 01:48, john_perry_u
On Sunday, November 16, 2014 6:34:56 AM UTC, Clemens Heuberger wrote:
>
> > Works for me, possibly because I have a newer git.
> Can it be that it works for you because the commit
> ec0aae9358f5204a3db6406b2c2f2818a78f5892 (this is the actual commit of
> #16747)
> is contained in your local rep
It seems to me that there is newgroup etiquette that for this group should
include anyone requesting anyone else to move a discussion to private
mail, or to sage-flame. At least for a while.
Common courtesy would be to agree, even if
it might not be entirely to your liking.
Changing code is mo
30 matches
Mail list logo
