Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Jeroen Demeyer

On 2014-11-18 23:15, Andrew wrote:

That is, the manual states that the recommended route is to use sage -br
unless you are modifying packages.
The manual is technically correct but can easily be misinterpreted. The 
problem is that switching branches often *does* modify packages.


In some cases (a package upgrade which isn't tied closely to the Sage 
library), you can get away with "./sage -b" and not building the new 
package, but for some package changes, you really need to run "make".


My workflow is:
1. checkout the relevant branch that I want to work on
2. run "make"
3. make edits (this can be done in parallel with 2)
4. run "./sage -br"
5. goto 3

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread William Stein
On Tue, Nov 18, 2014 at 2:15 PM, Andrew  wrote:
>
>> > I've gone back to sage -b.
>> Please don't, or at the very least don't ever report a bug or failing
>> doctest without doing "make" first.
>
>
> I am confused by Jeroen's comment. According to the sage 6.4 developers
> guide:
>
> Rebuilding Sage
>
> Once you have made any changes you of course want to build Sage and try out
> your edits. As long as you only modified the Sage library (that is, Python
> and Cython files under src/sage/...) you just have to run:
> [user@localhost sage]$ ./sage -br
>
> to rebuild the Sage library and then start Sage. This should be quite fast.
> If you made changes to third-party packages then you have to run:
> [user@localhost sage]$ make
>
> as if you were installing Sage from scratch. However, simply running make
> will only recompile packages that were changed, so it shoud be much faster
> than compiling Sage the first time. Rarely there are conflicts with other
> packages, or with the already-installed older version of the package that
> you changed, in that case you do have to recompile everything using:
> [user@localhost sage]$ make distclean && make
>
> Also, don't forget to run the tests (see Doctesting the Sage Library) and
> build the documentation (see The Sage Manuals).
>
>
> That is, the manual states that the recommended route is to use sage -br
> unless you are modifying packages. Does the manual need to be updated or do
> Jeroen's comments only apply when playing with external packages/code?
>
> Btw, as William mentioned in another post, sage's requirement to use sage
> -br, or make, when python files are changed shouldn't be necessary (cf. for
> example, this is done automatically when using setup tools). Are their plans
> to fix this?

Yes, definitely. We're I think just literally waiting for somebody
persistent to decide to do it. There's no real downside.
It was also dramatically reduce a massive source of confusion, where a
person does

  foo??

in some context (maybe sage or ipython), or maybe just uses "find" on
the command line, then tries to directly edit the file based on the
listed source code location.

There's also potentially a small savings of disk space.

>
> Andrew
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Andrew


> > I've gone back to sage -b. 
> Please don't, or at the very least don't ever report a bug or failing 
> doctest without doing "make" first. 
>

I am confused by Jeroen's comment. According to the sage 6.4 developers 
guide 
:

Rebuilding Sage 

Once you have made any changes you of course want to build Sage and try out 
your edits. As long as you only modified the Sage library (that is, Python 
and Cython files under src/sage/...) you just have to run: 
[user@localhost sage]$ ./sage -br

to rebuild the Sage library and then start Sage. This should be quite fast. 
If you made changes to third-party packages then you have to run: 
[user@localhost sage]$ make

as if you were installing Sage from scratch 
. However, simply 
running make will only recompile packages that were changed, so it shoud be 
much faster than compiling Sage the first time. Rarely there are conflicts 
with other packages, or with the already-installed older version of the 
package that you changed, in that case you do have to recompile everything 
using: 
[user@localhost sage]$ make distclean && make

Also, don’t forget to run the tests (see Doctesting the Sage Library) and 
build the documentation (see The Sage Manuals).


That is, the manual states that the recommended route is to use sage -br 
unless you are modifying packages. Does the manual need to be updated or do 
Jeroen's comments only apply when playing with external packages/code?

Btw, as William mentioned in another post, sage's requirement to use sage 
-br, or make, when python files are changed shouldn't be necessary (cf. for 
example, this is done automatically when using setup tools). Are their 
plans to fix this?

Andrew


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Felix Salfelder
On Tue, Nov 18, 2014 at 03:35:57AM -0800, Volker Braun wrote:
> The problem with union file systems is that you don't have a good option on 
> OSX (e.g. forget about the built-in union fs). 

Hi Volker.

i dont think that reviews made on non-OSX computers are inferior. and,
nobody would keep you from recompiling on OSX, while other platforms do
better. anyway there must be something like cp -a on OSX, and can
probably be used instead, to bridge the semantics -- until OSX gets a
suitable update. yes, there might be some impact on efficiency, clearly
SEP...

note that sage includes conditional stuff that only works for OSX, and
is of no use otherwise (which is not a bad thing!).

cheers
felix

PS: i have not used aufs or anything like it. it appears to potentially
solve a problem. if its not perfect, maybe recompilations are still
worse.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread kcrisman

>
>
> > Also part of the problem is the use of 'make' that is recommended 
> Yes, and there are good reasons for this. 
>
> > I've gone back to sage -b. 
> Please don't, or at the very least don't ever report a bug or failing 
> doctest without doing "make" first. 
>
> The problem with "sage -b" is that you *include* Sage library changes 
> because of a new package version but you *exclude* the actual package 
> changes. 
>
>
Ah, I only do this when checking out Sage library-only branches that I then 
merge develop into (which is okay because I am only reviewing them, not 
committing), for exactly this reason.  
 

> Forget your past experiences and try again now that we have #17286. 
>
>
Okay, we'll see! That certainly should help a lot.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Jeroen Demeyer

On 2014-11-17 15:03, kcrisman wrote:

Also part of the problem is the use of 'make' that is recommended

Yes, and there are good reasons for this.


I've gone back to sage -b.
Please don't, or at the very least don't ever report a bug or failing 
doctest without doing "make" first.


The problem with "sage -b" is that you *include* Sage library changes 
because of a new package version but you *exclude* the actual package 
changes.


Forget your past experiences and try again now that we have #17286.


Jeroen.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Volker Braun
On Tuesday, November 18, 2014 8:12:42 AM UTC, Felix Salfelder wrote:
>
> - aufs [2]. use an overlay for reviewing. afterwards discard it and return 
>   to the previous state. 
>

The problem with union file systems is that you don't have a good option on 
OSX (e.g. forget about the built-in union fs). 

Even better: docker images can build on other images, just create a new 
container for each review and destroy the container when you are finished. 
But no native support on OSX. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-18 Thread Felix Salfelder
On Mon, Nov 17, 2014 at 05:57:53PM -0800, Andrew wrote:
> When the branch is finally ready for review it has to be merged with the 
> latest development branch, so you can't avoid this indefinitely. As with 
> Nathan, I'm reluctant to continuously switch between versions because of 
> the compile time lag. 

hi there.

some thoughts

- there is no such thing as a 'reviewed' branch. if a review
  corresponded to a merge into 'reviewed', no switching back (to develop?
  master?) would be necessary (in theory..)

- git-new-workdir (part of git) [1] permits multiple work directories on
  top of one repository. this makes multiple builds more efficient, such
  as one for production and one for review.

- aufs [2]. use an overlay for reviewing. afterwards discard it and return
  to the previous state.

hth
felix

[1] -> search engine, tons of resources available.
[2] http://aufs.sourceforge.net

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Andrew


> Nathann-bashing has become a game or what ?... 
>

Sorry, wasn't intended as Nathan-bashing: I was just referring to your 
previous comment.
 

> The problem with your method is that you change all timestamps. I do 
> it reverse: fetch the remote branch, and merge it into develop. No 
> change in the timestamps. 
>

OK, will try this in future. Of course, this doesn't work with branches 
that have not been pushed to trac. When push pushing to trac I guess that 
rebase -i should be used to prune the local commits to something 
reasonable. 
 

The recommended way is to stay on the old version unless you actually need 
> something from the latest development branch. 
>

When the branch is finally ready for review it has to be merged with the 
latest development branch, so you can't avoid this indefinitely. As with 
Nathan, I'm reluctant to continuously switch between versions because of 
the compile time lag. 

Andrew



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Nathann Cohen
Hello !

> I read that as just repeating what you said as a statement, but I may have
> misread it?

Well, the branch I had in mind had something like 5-6 commits and all
had the same message "merged with develop" or something. No way to
know what was happening, and of course they were not only merge
commits as code was implemented there. I don't see anything wrong with
a branch that is merged with the latest release at some point,
whichever the direction.

> See, the fact that one has to understand all these things - ALL OF WHICH ARE
> NON-MATHEMATICAL - is the entire problem.

Yep. I will try to read the developper's manual this weekend to see if
anything can be made clearer. There has to be a way.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread kcrisman

>
> > This pull a lot of (unclean) garbage into my history so I am guessing 
> that, 
> > on principle, Nathan would refuse to review such patches when they are 
> done. 
>
> Nathann-bashing has become a game or what ?... 
>
>
I read that as just repeating what you said as a statement, but I may have 
misread it?
 

> I would see nothing wrong with that branch. By the way on trac the 
> diff file would only show the content of your branch. 
>
> The problem with your method is that you change all timestamps. I do 
> it reverse: fetch the remote branch, and merge it into develop. No 
> change in the timestamps. 
>
>
See, the fact that one has to understand all these things - ALL OF WHICH 
ARE NON-MATHEMATICAL - is the entire problem.  I agree with John that one 
shouldn't have to wait forever for a recompilation - during which it is 
presumably not safe to try other branches on the same Sage install? - when 
just checking a minor change. I also now always *review* by branching from 
develop and then pulling the branch to that 'safe' branch, but even then 
when I go back to develop sometimes it takes exceedingly long. 
 See https://groups.google.com/d/msg/sage-devel/iGxa2F01rFc/ERRec52gHY0J

Also part of the problem is the use of 'make' that is recommended; I've 
gone back to sage -b and sometimes that helps.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Nathann Cohen
> This pull a lot of (unclean) garbage into my history so I am guessing that,
> on principle, Nathan would refuse to review such patches when they are done.

Nathann-bashing has become a game or what ?...

I would see nothing wrong with that branch. By the way on trac the
diff file would only show the content of your branch.

The problem with your method is that you change all timestamps. I do
it reverse: fetch the remote branch, and merge it into develop. No
change in the timestamps.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Volker Braun
On Monday, November 17, 2014 12:43:28 PM UTC, Andrew wrote:
>
> OK, so if I have a branch that is using an old version of sage what is the 
> recommended way of moving it up to the latest development branch.
>

The recommended way is to stay on the old version unless you actually need 
something from the latest development branch.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Andrew


On Monday, 17 November 2014 22:53:53 UTC+11, Volker Braun wrote:
>
> On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote:
>>
>> Volker, I am not telling you that having bad histories is good
>>
>
> So we agree, perfect ;-)
>
>
OK, so if I have a branch that is using an old version of sage what is the 
recommended way of moving it up to the latest development branch. What I 
have been doing is updating the develop branch and then

> git checkout my_branch
> git merge develop

This pull a lot of (unclean) garbage into my history so I am guessing that, 
on principle, Nathan would refuse to review such patches when they are done.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Nathann Cohen
>> Volker, I am not telling you that having bad histories is good
>
> So we agree, perfect ;-)
>
> Really the problem is that we rely on time stamps for deciding what to
> compile. That is a technical issue that we'll fix eventually.



There is something wrong with the world. Sometimes I think that it is
only me, but on some other occasions there is no doubt possible. The
world is wrong.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Volker Braun
On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote:
>
> Volker, I am not telling you that having bad histories is good
>

So we agree, perfect ;-)

Really the problem is that we rely on time stamps for deciding what to 
compile. That is a technical issue that we'll fix eventually.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Nathann Cohen
Yo !

> Its not just me, ask any lager project that is using git. Half of them even
> force you to clean up your history before submitting anything.

Volker, I am not telling you that having bad histories is good, I am
telling you that letting newcomers not care about the amount of merge
commits is not a problem for us. We already do that to some extent:
when I see a newcomer here I make very very long reviews about all
points of doc and doctests, and from time to time I do these changes
myself telling them what he should pay attention to. That is normal.

I remember having refused to review a patch because the history was
awful, and this is something I did because the reviewer was
experienced.

So let us insist on having clear histories, because indeed, like the
code, "history is read much more often than it is written", but that
is not such a big problem if the first 2~3 patches of a newcomer have
one or two commit merges.

Again, you only create a merge commit when the development of a ticket
lasts over several beta releases, and in my experience this is rare
for newcomers. Newcomers patches are never fundamental stuff, and this
will not be a problem in the long run. So even if it is just to
prevent them from recompiling Sage when they want to fix a typo in the
doc, let's make it easy for them. If they stick around they will get
to learn git anyway.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-17 Thread Volker Braun
On Monday, November 17, 2014 3:06:42 AM UTC, Nathann Cohen wrote:
>
> You declared that "unnecessary merges are bad" 
>

Its not just me, ask any lager project that is using git. Half of them even 
force you to clean up your history before submitting anything. 

The log is not just there for the reviewer, it is fixed for all time in our 
history and if you ever want to figure out where a particular line comes 
from ("git blame") then you'll have to be able to understand the history 
around the commit.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Nathann Cohen
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 when I completely
> juiced my system... which wasn't an empty set, but it wasn't of large
> cardinality, either.

Well, if you systematically merge the remote branch with the latest release
available on your computer, git behaves like hg and you only have to
recompile the files modified by the branch.

I have a script that does something like that:

git branch -D tmp
git checkout -b tmp develop
git pull trac remote_branch

When the remote branch was already up-to-date it creates no commit, it is
just a 'fast-forward' in git's terminology

When the remote branch is not up-to-date but there is no conflict, I just
fill a commit message saying "trac #number: rebased on the latest beta"

When the remote branch is not compatible with the latest release I fix the
problems then create the merge commit.

I insist that this way of doing things make it behave like mercurial did
with respect to recompilations. Also, I worked like that for a long time
and my branches usually have no merge commit (when they get reviewed
between two betas) or one for the longest ones. Sometimes they have two,
for very very long ones (but I usually rebase them when they get this old).

What I mean to say is that if beginners write branches with one or two
merge commits, this is not a very hard price to pay to make it easier for
them. Plus beginners branches are usually simple things, which are quickly
reviewed: thus there should be no merge commit at all.

Finally, I think that this is the best procedure to *review* branches, as
it triggers the minimum amount of recompilation and there is no problem
with the branch history as everything only happens on the reviewer's
computer.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Nathann Cohen
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 branch.

When working on a ticket we often have to merge anyway as the branch
becomes incompatible with the latest beta.

I have seen branches with bad git history and the problem was not the
many merge commits: it was the lack of proper/clear commit messages.
Also, they misunderstood the role of commits: they are there to make
sense to the reviewer, and to help him understand how the code is
written.

I have been working this way since the beginning and I do not think
anybody found my branches particularly messy.

If you want to insist on the religious point that "unnecessary merges
are bad", I really believe that this is how we should teach our
newcomers, for it is already sufficiently painful to contribute at
first, with all rules we have for code. And you can enforce a religion
on them later on if you want to.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Travis Scrimshaw

>
>
> 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 not even be able to start Sage because of more recent 
spkgs. If that's what I have to do, then I'm never going to review someone 
else's ticket I don't know if they mind merges to latest develop. (However 
I do take responsibility for not explicitly mentioning that I merged the 
latest develop.)

   Merging with the latest develop branch is not unnecessary as it is 
something that must be done and it would put my Sage development into a 
standstill as I almost always need the latest develop. IMO unnecessary 
merges are those where *small* unrelated changes are made to a base branch 
and merged in 1 by 1. I'm more than willing to spend time and energy to 
teach people git usage to reduce large re-compilations.

Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread john_perry_usm
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 Python code. If we could download & test patches as before, this 
>> wouldn't be a problem.
>>
>
> 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.
>

Oh, wait: are you talking about having to trace back through different 
tickets, on those occasions where there *was* a significant difference? In 
that case, yes, it was labor-intensive, and automating by git is great. No 
argument there.

To repeat what I said in another thread: I don't object to git; I 
understand why it's been adopted (I'm actually using git at the moment on 
another system), and I had see the "git try ..." think before, so I realize 
the major developers recognize & are working on it. I'm not questioning all 
that.

What I'm saying is that, for all the present setup's advantages with medium 
to large changes, forcing the casual developer to recompile frequently, on 
very minor changes, is a big disincentive. So if "git show " obtains 
a usable patch that I can apply as before (I will try it at some point) 
then that should go into the developer's manual.

john perry

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread john_perry_usm


> 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, I had bigger problems 
trying to write code Nathann liked, and trying to explain my needs, than I 
did with applying the patches. And that was *with* Cython recompilations.

john perry

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread William Stein
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
review.

If you work on nonsage python projects they mostly support e.g. "pythob
setup.py develop" for this sort of thing.

William.
On Nov 16, 2014 12:59 PM, "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 Python code. If we could download & test patches as before, this
>> wouldn't be a problem.
>>
>
> 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.
>
> Second, wouldn't that test against the development version have to be made
>> at some point, anyway?
>>
>
> The trac ticket shows whether there is a merge conflict, if there isn't
> one then there is no need to test it by hand.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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't be a problem.
>

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.

Second, wouldn't that test against the development version have to be made 
> at some point, anyway?
>

The trac ticket shows whether there is a merge conflict, if there isn't one 
then there is no need to test it by hand. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread john_perry_usm
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 can think of lots of reasons how unpacking the binary tarball (and the 
> relocation script) can screw up time stamps. In any case, this is unrelated 
> to git.
>

Okay, yes, in hindsight that's obvious. I suspect that's the reason for the 
first recompile.
 

> *After* that, Travis Scrimshaw made some very helpful changes, but he did 
>> them based on the development version. So, when I tried to work with it, so 
>> as to give it a positive review (which actually needed more work)... cue 
>> another complete rebuild of Sage.
>>
>
> Really that is Travis' fault for doing an unnecessary merge. Which, in 
> turn, forced you to recompile to follow the merge.
>

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't 
be a problem. As it is, I basically gave the ticket a positive review by 
following his advice & hand-copying a few more changes he made, which is 
morally equivalent to the old way. :-) Second, wouldn't that test against 
the development version have to be made at some point, anyway?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Eric Gourgoulhon


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 no longer a named 
> branch, so you can't push it accidentally)
>
> git checkout --detach develop
> git fetch trac u/user/descrption
> git merge FETCH_HEAD
>
>
Thanks for the explanation.

Eric. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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 far apart then you could use more than one Sage installation, 
you can even share the upstream/ folder with a symlink. 



 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Anne Schilling


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.
>>
>
> I can think of lots of reasons how unpacking the binary tarball (and the 
> relocation script) can screw up time stamps. In any case, this is unrelated 
> to git.
>
> *After* that, Travis Scrimshaw made some very helpful changes, but he did 
>> them based on the development version. So, when I tried to work with it, so 
>> as to give it a positive review (which actually needed more work)... cue 
>> another complete rebuild of Sage.
>>
>
> Really that is Travis' fault for doing an unnecessary merge. Which, in 
> turn, forced you to recompile to follow the merge.
>

Well, not necessarily. I had the following situation recently: I was 
reviewing two tickets based on two different versions of Sage. Every time I 
moved between the branches, everything had to recompile. So at the end I 
rebased one of the patches to the most current version of Sage, so that I 
could review the tickets simultaneously. How else would you handle this 
situation? Of course that forced the author of the patch to recompile once 
for a long time ...

Best,

Anne 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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 
relocation script) can screw up time stamps. In any case, this is unrelated 
to git.

*After* that, Travis Scrimshaw made some very helpful changes, but he did 
> them based on the development version. So, when I tried to work with it, so 
> as to give it a positive review (which actually needed more work)... cue 
> another complete rebuild of Sage.
>

Really that is Travis' fault for doing an unnecessary merge. Which, in 
turn, forced you to recompile to follow the merge.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread john_perry_usm
...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 
juiced my system... which wasn't an empty set, but it wasn't of large 
cardinality, either.

Basically, would it be possible to add an intermediate step where people 
could download only the relevant patch (like before), apply & experiment 
only with the patch (like before), & then, when that seemed okay, check 
against the most recent branch (like now)? Sorry if this sounds like 
ignorant babble; I'm not familiar with the correct vocabulary.

john perry

On Sunday, November 16, 2014 7:53:43 PM UTC+1, john_perry_usm wrote:
>
> 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 in the local 
>> history. 
>>
>
> Thanks for paying attention to that. :-)
>
> If I understand correctly, your proposals fix the problem with tickets, 
> but I think there's a bigger problem. Or, maybe I just don't understand, 
> but if so, you can correct me here, and that should save me trouble later, 
> right?
>
> In the most recent debacle that constitutes my attempts to help with Sage 
> ;-) I followed the steps listed in the developer's guidelines from the most 
> recent release: checked out a branch (apparently it checks out itself, 
> though I'm not sure) then modified the few lines of Python code, then 
> executed ./sage -br. Cue the complete rebuild of Sage. (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.)
>
> *After* that, Travis Scrimshaw made some very helpful changes, but he did 
> them based on the development version. So, when I tried to work with it, so 
> as to give it a positive review (which actually needed more work)... cue 
> another complete rebuild of Sage.
>
> I don't see how the proposed change would have fixed either problem. Sorry 
> if this is completely off base, but I thought the extra clarification might 
> help.
>
> john perry
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread john_perry_usm
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 in the local 
> history. 
>

Thanks for paying attention to that. :-)

If I understand correctly, your proposals fix the problem with tickets, but 
I think there's a bigger problem. Or, maybe I just don't understand, but if 
so, you can correct me here, and that should save me trouble later, right?

In the most recent debacle that constitutes my attempts to help with Sage 
;-) I followed the steps listed in the developer's guidelines from the most 
recent release: checked out a branch (apparently it checks out itself, 
though I'm not sure) then modified the few lines of Python code, then 
executed ./sage -br. Cue the complete rebuild of Sage. (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.)

*After* that, Travis Scrimshaw made some very helpful changes, but he did 
them based on the development version. So, when I tried to work with it, so 
as to give it a positive review (which actually needed more work)... cue 
another complete rebuild of Sage.

I don't see how the proposed change would have fixed either problem. Sorry 
if this is completely off base, but I thought the extra clarification might 
help.

john perry

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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 --detach develop
git fetch trac u/user/descrption
git merge FETCH_HEAD

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Eric Gourgoulhon
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 from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Nathann Cohen
>> 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 them (+does not hurt
anyone), and to tell them later that we don't like it (if for some
reason we don't), and you make me say "everybody else is stupid".

I give up. It's getting late here anyway.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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 who is using git and discourages unnecessary merges is just 
stupid and hasn't realized it yet. Possible, but unlikely reason.

>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Nathann Cohen
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 very real cost in unnecessary merges, they make the log
harder
> to read.

Well, first when the guy only wants to review/checkout a branch you do not
care, because it is only done on his computer.

Then, it is not that big of a problem, really. In most tickets there is no
need for a merge as they are written between two releases, and otherwise
you have one merge commit when you set a ticket to needs_work because there
is some conflict. The merge is the last of the branch, and usually that is
all.

> 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. And that it a big problem of ours at the moment.

We could tell them later on that we prefer them to rebase the branches or
something, but well.. Really I have been writing dozens of tickets this way
and I do not think that the git histories were so ugly.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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 they 
discourage unnecessary merges.



On Sunday, November 16, 2014 4:40:26 PM UTC, Eric Gourgoulhon wrote:

> 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 the trac branch 
> is based on a version of Sage that is older than that of 
> the user, this should not trigger a full recompilation, contrary to the 
> previous instruction.
>
>
> Eric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Eric Gourgoulhon
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 the trac branch is 
based on a version of Sage that is older than that of 
the user, this should not trigger a full recompilation, contrary to the 
previous instruction.


Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Nathann Cohen
> 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 ?

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: About recmpilations caused by Git

2014-11-16 Thread Volker Braun
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_usm > 
> wrote: 
> > 
> > (1) When switching development to Git, it became harder for the less 
> > talented to contribute. I'm not the only one who encountered a complete 
> > recompilation of Sage when reviewing a new ticket -- even one that 
> didn't 
> > touch Cython. See, e.g., some of my comments on ticket #17298, where at 
> one 
> > point I wrote, "I can't afford to tie up my installation for 2 hours of 
> > compilation every time a few lines of Python code change." 
> > 
> > This used not to occur in Mercurial. 
>
> 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 in the local 
> history. 
>
> Thing is that to my experience this is the only reason why git 
> triggers big recompilations. So what having a git hook saying 
> something like "you cannot checkout this branch, it is too old. If you 
> want to use it, merge it with the latest beta instead" ? 
>
> And we could have some "-f" flag when we really want to do that... But 
> that would prevent newcomers from wasting a couple of hours. 
>
> Nathann 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.