Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#11121 closed enhancement (fixed)

Set up good defaults for sage's mercurial

Reported by: kini Owned by: tbd
Priority: major Milestone: sage-4.7.2
Component: packages: standard Keywords: mercurial git diff patches sd31
Cc: iandrus Merged in: sage-4.7.2.alpha2
Authors: Keshav Kini, John Palmieri Reviewers: John Palmieri, Keshav Kini
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #10594 Stopgaps:

Description (last modified by jdemeyer)

Apply:


As above. See some discussion at sage-devel.

This would involve making the Mercurial spkg install an hgrc at $SAGE_LOCAL/etc/mercurial/hgrc as well as adding lines to .hg/hgrc in the major repositories in the sage distribution (., data/extcode, devel/sage/, devel/sagenb/, and local/bin/). I exclude examples and spkg/base because they are scheduled to be gotten rid of (#7494 and #11073 respectively).

Attachments (9)

trac_11121-hgrc.data-extcode.patch (624 bytes) - added by kini 8 years ago.
apply to $SAGE_ROOT/data/extcode
trac_11121-hgrc.devel-sagenb.patch (554 bytes) - added by kini 8 years ago.
apply to $SAGE_ROOT/devel/sagenb
trac_11121-hgrc.local-bin.patch (713 bytes) - added by kini 8 years ago.
apply to $SAGE_ROOT/local/bin
trac_11121-hgrc.sage.patch (463 bytes) - added by kini 8 years ago.
apply to $SAGE_ROOT
trac_11121-hgrc.devel-sage.patch (1.8 KB) - added by kini 8 years ago.
apply to $SAGE_ROOT/devel/sage
trac_11121-hgrc.mercurial-spkg.patch (1.2 KB) - added by kini 8 years ago.
don't use this, I'll upload a full spkg
trac_11121-root-repo.patch (878 bytes) - added by jhpalmieri 8 years ago.
apply to $SAGE_ROOT
trac_11121-scripts-sage-clone.patch (916 bytes) - added by jhpalmieri 8 years ago.
scripts repo
trac_11121-hgrc.local-bin-mode0755.patch (681 bytes) - added by jdemeyer 8 years ago.
Same as trac_11121-hgrc.local-bin.patch but keeping the file mode 0755

Download all attachments as: .zip

Change History (72)

comment:1 Changed 8 years ago by kini

  • Description modified (diff)
  • Summary changed from Mercurial spkg should install an hgrc which turns on git-style diffs to Sage should use git-style diffs everywhere possible.

comment:2 Changed 8 years ago by kini

  • Description modified (diff)
  • Status changed from new to needs_review

These patches set the default diff format to git's new diffs (as opposed to the default which is the old unified diff spec) and add some (IMHO) very useful extensions to the default hgrc. Any comments / suggestions?

comment:3 Changed 8 years ago by kini

  • Summary changed from Sage should use git-style diffs everywhere possible. to Set up good defaults for sage's mercurial

comment:4 Changed 8 years ago by kini

  • Description modified (diff)

comment:5 Changed 8 years ago by kini

By the way, I also added a comment to the top of $SAGE_LOCAL/bin/sage-spkg-install explaining what it's for, and changed its file permissions to make it non-executable (it becomes executable when turning into spkg-install in the various SPKGs it's a template installer for, anyway).

comment:6 Changed 8 years ago by was

  • Status changed from needs_review to needs_work
  1. Dumb question: Isn't this patch going to make it so every time one installs the mercurial spkg,
    [diff]
    git = true
    

gets appended to $TARGET/.hg/hgrc? If one upgrades, hence install mercurial multiple times, this seems very bad.

  1. Same remark about $SAGE_LOCAL/etc/mercurial/hgrc.

comment:7 Changed 8 years ago by kini

Nope, it's > rather than >> so it overwrites the file rather than appending.

comment:8 Changed 8 years ago by kini

  • Status changed from needs_work to needs_review

Were there any other work issues? If not I'll set this back to "needs review" but of course feel free to revert it again...

comment:9 Changed 8 years ago by jhpalmieri

  • Status changed from needs_review to needs_work

I don't think the patch to the $SAGE_ROOT/local/bin is doing what you want. The file being patched there is just the spkg-install file for the scripts repository; it's not a template for general spkg-install files. (So if nothing else, your new comment at the top of the file should be changed or deleted.) If you want to patch other spkg-install files, you'll have to patch each repository -- the Sage library, extcode, and sagenb -- individually.

comment:10 Changed 8 years ago by kini

Wow, I'm not sure how I screwed that one up so badly... d'oh. You are absolutely right. I'll upload new patches tomorrow - thanks for the pointer!

Changed 8 years ago by kini

apply to $SAGE_ROOT/data/extcode

Changed 8 years ago by kini

apply to $SAGE_ROOT/devel/sagenb

Changed 8 years ago by kini

apply to $SAGE_ROOT/local/bin

comment:11 Changed 8 years ago by kini

  • Description modified (diff)

comment:12 follow-up: Changed 8 years ago by dimpase

nothing must be done to local/bin in your patches, which doesn't even exist in a source distribution. You need to patch the source instead.

comment:13 Changed 8 years ago by kini

... OK, I very apparently don't know what I'm doing. I'll do some more poking around and learning before marking this needs_review again... sorry for the email spam.

comment:14 in reply to: ↑ 12 ; follow-ups: Changed 8 years ago by jhpalmieri

Replying to dimpase:

nothing must be done to local/bin in your patches, which doesn't even exist in a source distribution. You need to patch the source instead.

$SAGE_ROOT/local/bin is the Sage scripts repo, so it's fine to patch it. Or maybe I don't understand your complaint.

Kini, do you also want to patch the Sage root repo? Its spkg-install file is SAGE_ROOT/spkg/root-spkg-install.

comment:15 in reply to: ↑ 14 Changed 8 years ago by dimpase

Replying to jhpalmieri:

Replying to dimpase:

nothing must be done to local/bin in your patches, which doesn't even exist in a source distribution. You need to patch the source instead.

$SAGE_ROOT/local/bin is the Sage scripts repo, so it's fine to patch it. Or maybe I don't understand your complaint.

my bad, I didn't know that some parts of local/bin are actually in the scripts spkg...

comment:16 in reply to: ↑ 14 Changed 8 years ago by kini

  • Description modified (diff)

Replying to jhpalmieri:

Replying to dimpase:

nothing must be done to local/bin in your patches, which doesn't even exist in a source distribution. You need to patch the source instead.

$SAGE_ROOT/local/bin is the Sage scripts repo, so it's fine to patch it. Or maybe I don't understand your complaint.

Kini, do you also want to patch the Sage root repo? Its spkg-install file is SAGE_ROOT/spkg/root-spkg-install.

Got it. Yes, I'll do that...

Changed 8 years ago by kini

apply to $SAGE_ROOT

comment:17 Changed 8 years ago by kini

Trying out sage-sdist I find that making hg diff go to a pager by default might screw up some of the scripts (or at the very least cause them to become interactive when they shouldn't be). This is bad, but should I make hg diff not go to a pager by default, or just stick a --pager= on any usages of hg diff in scripts? Paging diffs is a really nice feature that I think should be standard, but on the other hand it seems a bit intrusive to have to explicitly specify --pager= in a script.

Then again, why are we even running hg diff in scripts? All the examples of this I could find were either just standalone lines running hg diff, or, in one case, local/bin/sage-pkg, an attempt to figure out whether uncommitted changes existed in the directory (which could just as easily be done by searching $(hg summary) for "(clean)", if I'm not mistaken.

Any comments?

comment:18 Changed 8 years ago by jhpalmieri

I'm a little wary of changing the default behavior in so many ways. In general, wouldn't it be good enough to point to the Mercurial extensions page and let people pick for themselves? Or we could recommend some good choices. We could do this in the developer's guide, when we discuss using Mercurial. I guess it seems that enabling these extensions reflects the opinions of a few people, and it might be safer to just implement a few important changes (like git=true). Anyway, here are some of my questions and opinions:

[trusted] 
users = $USER     is this necessary?  what happens if we leave this out?

[diff] 
git = true        seems like a good idea

[extensions] 
color =           innocuous
graphlog =        innocuous, but should it be "hgext.graphlog="?  That's what the docs say.
mq =              useful, keep it
pager =           see my comments below.
progress =        innocuous
purge =           should this be "hgext.purge="?  provides a potentially useful, but potentially dangerous, command
rebase =          seems okay, but I've never used it
record =          "hgext.record="?
relink =          seems okay, but never used it
transplant =      seems okay, but never used it

Regarding "pager": first, should we follow the Mercurial suggestions and do

[pager]
pager = LESS='FSRX' less

Second, if we use the pager extension, will it interfere with Sage functions like hg_sage.diff()? These are defined in SAGE_ROOT/devel/sage/sage/misc/hg.py, and they call a pager already, a different one depending on whether working from the command-line or in the notebook.

comment:19 Changed 8 years ago by jhpalmieri

Actually, let me revise one comment: the "color" extension is not innocuous: when it's enabled, the output from "hg_sage.status()" in the notebook has stray characters, presumably coming from the ASCII color-changing codes. It looks like this:

Getting status of modified or unknown files:
cd "/Applications/sage/devel/sage" && hg status
[0;34;1mM sage/algebras/steenrod_algebra_bases.py[0m

The last line should be

M sage/algebras/steenrod_algebra_bases.py

On the other hand, with the color extension enabled, the output looks good from the command line. So if we want to use color, we should have separate hgrc files, one for the notebook and one for the command-line.

I'm a little suspicious of enabling some of the others of these in the notebook, for example "progress". On the bright side, enabling "pager" doesn't seem to have any detrimental effect in the notebook.

comment:20 Changed 8 years ago by jhpalmieri

See #11142 for a way to deal with the "pager" and "color" issues. With the patch there, we should definitely turn on the pager extension, and we can turn on the color extension without breaking anything in the notebook.

comment:21 follow-up: Changed 8 years ago by kini

John, thanks for your comments, and your fast work on #11142! I agree with you that most of the defaults set in my patch are just personal preference, but I did try to add all extensions that seemed relevant. Let me go down the list:

  • users = $USER is put there on the assumption that whoever is installing the mercurial SPKG will also be the owner of the files in the sage installation. All the other patches are applied towards creating .hgrc files in [repository root]/.hg/hgrc, which is not parsed when using mercurial unless the file is either owned by the same person as the person who is invoking hg, or the owner of [repository root]/.hg/hgrc is listed as a trusted user in some other hgrc file which HAS been read (such as this one, $SAGE_ROOT/local/etc/mercurial/hgrc.
  • git = true was the original point of this ticket :)
  • Prepending hgext. is apparently unnecessary in newer versions of Mercurial, says #mercurial on freenode. I was even invited to submit a patch to the man page for hgrc...
    • color is nice on the commandline.
    • graphlog is indispensable (imho) for seeing what exactly is going on with the history of a particular mercurial repository.
    • mq is of course useful.
    • pager is useful.
    • progress is not really necessary - if it interferes with the notebook I guess it's better to get rid of it.
    • purge is not all that important, but since it only adds a new command it shouldn't screw up anything else.
    • rebase is great for rebasing mq patches on new versions of sage, something I'll need in order to fix #10988, I think.
    • record is useful.
    • relink seems nice for people who use sage -clone, though I don't use either myself.
    • transplant seems to be useful in some way, but I've never used it either (maybe not that great of an idea to include, then.)
  • The suggestions for parameters to less given on the Mercurial wiki are also a matter of personal preference. By default, less doesn't leave anything in the terminal after it exits (it restores whatever was on the screen before you called it), but the X option disables this behavior. The F option also disables this behavior, in a sense, by acting like cat when the screen is large enough to take the entire output. The S option truncates long lines instead of wrapping them. The R option (which is in my patch) displays (ANSI) terminal color codes. My preference is still to just keep R of these four, but whoever wrote the Mercurial wiki article disagrees. It's not really possible to be that objective about this, I think...

I'll go take a look at #11142.

comment:22 Changed 8 years ago by iandrus

  • Cc iandrus added

Changed 8 years ago by kini

apply to $SAGE_ROOT/devel/sage

comment:23 Changed 8 years ago by kini

I'm going to upgrade Mercurial to 1.8.4 and incorporate this and #11120 into the new spkg.

comment:24 follow-up: Changed 8 years ago by jhpalmieri

Before you put too much effort into upgrading Mercurial, read this comment. Unless there is a strong argument for it, it looks like a new version of Mercurial isn't likely to get merged.

comment:25 in reply to: ↑ 24 Changed 8 years ago by kini

Replying to jhpalmieri:

Before you put too much effort into upgrading Mercurial, read this comment. Unless there is a strong argument for it, it looks like a new version of Mercurial isn't likely to get merged.

Thanks for the heads up. I've packaged it already without any obvious trouble. I hope this doesn't mean we're going to be stuck with 1.6.4 forever? Surely we need to upgrade eventually. We're already two versions behind, soon to be three, a couple of weeks from now.

comment:26 in reply to: ↑ 21 Changed 8 years ago by kcrisman

Replying to kini:

John, thanks for your comments, and your fast work on #11142! I agree with you that most of the defaults set in my patch are just personal preference, but I did try to add all extensions that seemed relevant. Let me go down the list:

I'm confused. So does that mean that now anyone without a .hgrc file will automatically have all this?

In that case, I agree that maybe just the things that are necessary should be fixed, and the rest left optional but well documented in the devel manual.

comment:27 Changed 8 years ago by kini

Yeah, I'll just leave git diffs, color and pager for #11142, and rebase and relink because they will be useful in automated scripts in the future.

comment:28 Changed 8 years ago by kini

Er, sorry, and mq, of course.

Changed 8 years ago by kini

don't use this, I'll upload a full spkg

comment:29 Changed 8 years ago by kini

  • Authors set to Keshav Kini
  • Description modified (diff)
  • Keywords sd31 added
  • Status changed from needs_work to needs_review

OK, assuming I didn't forget anything, this spkg should obviate trac_11121-hgrc.mercurial-spkg.patch and make this ticket ready for review.

comment:30 Changed 8 years ago by jdemeyer

I disagree with

[pager] 
pager = less -R 
attend = annotate, cat, diff, log, glog, qdiff 

This looks too much like pushing your own personal preferences.

comment:31 Changed 8 years ago by jhpalmieri

I would be happy with

[pager]
pager = LESS='FSRX' less

since this is what is recommended on the Mercurial web page. (The "attend" setting above is almost the same, so I actually don't think that's a big deal, but it may be safest to just use what Mercurial advertises. That's as close to an official standard as we can get.)

comment:32 Changed 8 years ago by kini

Note that that page is a wiki and anyone can change it (indeed I just fixed a typo on it). In fact there are even people arguing about these LESS options (and even suggesting that people install the plan 9 pager!) at the end of the page. The official standard would be to not set any variables in .hgrc at all, but this ticket is all about not doing that.

Nevertheless I'll change the options to reflect what is written there since you insist.

comment:33 follow-up: Changed 8 years ago by jdemeyer

I would suggest not to put any pager variables at all.

comment:34 in reply to: ↑ 33 Changed 8 years ago by kini

Setting pager.attend to an empty value will cause all commands to be paged.

Or so says the hg man page. This seems more intrusive of a change than setting the attend variable. I guess choosing the pager itself is not necessary, so I'll skip it (#11142 sets it manually anyway).

comment:35 Changed 8 years ago by kini

OK, changed.

comment:36 follow-up: Changed 8 years ago by jhpalmieri

In the patch for the mercurial spkg, the hgrc file doesn't quite do what I would like. In particular, if there are no lines like

[pager]
pager = LESS='FSRX' less

then the pager extension doesn't do anything, so for example running "hg log" just scrolls through the whole log without pausing. Is that what you intended?

comment:37 Changed 8 years ago by kini

It is what I intended, because it is what Jeroen suggested I do. If you suggest I do otherwise, then in the interest of expediency I will follow the suggestion of whoever promises to review this first :P I have my own ~/.hgrc with pager = less -R in it anyway, so it doesn't much matter to me. As you said earlier, the most important thing here is to get "git=true" in there.

One benefit I can think of for not putting pager = LESS='FSRX' less in the hgrc is that the various scripts which (unwisely, in my opinion) call mercurial commands such as diff, log, status, etc. during build processes which are supposed to be unattended can be guaranteed not to halt waiting for someone to exit less, whereas at the moment, I, at least, have not vetted all such scripts to make sure this doesn't happen.

comment:38 Changed 8 years ago by jhpalmieri

Okay, that makes sense. Let's leave it the way you have it. (I have "pager= LESS ..." in my own .hgrc file, and I've never noticed any problems with Sage pausing during a build, but I think it's fine to leave it unset in the default hgrc file.)

comment:39 Changed 8 years ago by jhpalmieri

Since the file SAGE_LOCAL/etc/mercurial/hgrc sets "git=true", do we also need to set it for each repository individually? That is, do we need all of these patches, or just the one present in the new spkg in #10594?

comment:40 in reply to: ↑ 36 Changed 8 years ago by kcrisman

Replying to jhpalmieri:

In the patch for the mercurial spkg, the hgrc file doesn't quite do what I would like. In particular, if there are no lines like

[pager]
pager = LESS='FSRX' less

then the pager extension doesn't do anything, so for example running "hg log" just scrolls through the whole log without pausing. Is that what you intended?

So if someone doesn't have this set, then what would

hg_sage.log()

do? I tremble to think of the brand-new developer, who is not sure how to set up hg as an alias, trying this and being deluged by thousands of changes... At any rate, hg_sage.[tab] things should continue behaving as they have in this respect, using either 'more' or 'less' as the default (I don't know which it is, though). If the pager option breaks this, it should be a no-go in my opinion.

comment:41 Changed 8 years ago by kini

kcrisman: Review #11142 then! :)

jhpalmieri: The other patches ensure that the user will produce git patches from sage repositories even if they are simultaneously 1) using their system's Mercurial instead of sage -hg and 2) not using git diffs globally in their system's Mercurial.

comment:42 Changed 8 years ago by kini

kcrisman: Oops, you already are reviewing it. Sorry! :) Then to answer what I guess your actual question is, it won't make any difference as jhpalmieri's patch for #11142 manually uses less rather than relying on the hgrc file.

comment:43 Changed 8 years ago by kcrisman

So you're saying that

return '--config pager.pager="LESS=\'FSRX\' less"'

would keep the current behavior? I don't understand that part of it. What is FSRX?

So in principle, if one only merged this ticket, behavior would change, but if one then also merges #11142, it's ok. Is that right?

comment:44 Changed 8 years ago by jhpalmieri

I think if you only merge this ticket, behavior would stay the same, because the paging in commands coming from "hg_sage" (etc.) are done by hand in hg.py. For example, hg_sage.log() runs "sage -hg log | less", so it doesn't matter whether any hgrc file has a pager set.

FSRX are flags for the "less" command:

  • F exits automatically if the output fits on one screen
  • S truncates long lines
  • R preserves any color specification (and mercurial can use color in logs, diffs, etc.)
  • X doesn't clear the screen when you're done

comment:45 Changed 8 years ago by kcrisman

Thanks, John. I think I see that all now. And the flags are exactly the current behavior - convenient!

I won't be reviewing much until my normal computer comes back from the doctor, but then #11142 sounds like it will likely be good - once you do the things I suggest there ;) - and maybe this one too.

comment:46 Changed 8 years ago by kini

I'm not sure how they are "exactly the current behavior" - perhaps they are the defaults for less on your system? The less man page on my system at least explicitly says that -S is non-default behavior. And if we're going to stick to the manpage, it should technically be LESS='-FSRX', not LESS='FSRX'. Also, none of those four flags are in the POSIX spec for more. But no matter, since this is not going into the spkg anyway :)

comment:47 Changed 8 years ago by jhpalmieri

I have one new concern: the new notebook (the flask version) comes with a file .hg/hgrc, so I don't think we should overwrite it. It contains just this:

[paths]
default = https://rkirov-flask.googlecode.com/hg/

comment:48 Changed 8 years ago by kini

No, .hg/hgrc is not transferred across clones or pulls. Rather the file you are seeing was created by your local Mercurial when you did hg clone https://rkirov-flask.googlecode.com/hg/, to make it so that hg pull would by default pull from https://rkirov-flask.googlecode.com/hg/. When the flask notebook is distributed with sage, this hgrc file will not exist (or should not exist, otherwise our distribution tools are misusing Mercurial).

Changed 8 years ago by jhpalmieri

apply to $SAGE_ROOT

comment:49 Changed 8 years ago by jhpalmieri

I tried applying the patches, then running "sage -sdist ...", and then building from the resulting tar ball. The patch for the root repo isn't working; I think the spkg-install script is exiting before the part which creates the hgrc file. The code to create the hgrc file might have to appear several times in that file, since there are several places it can successfully exit. Maybe try trac_11121-root-repo.patch instead.

comment:50 Changed 8 years ago by kini

  • Description modified (diff)

Whoops, yes, you're right. Thanks for the patch.

comment:51 follow-up: Changed 8 years ago by jhpalmieri

  • Reviewers set to John Palmieri

One small issue: as you said, .hg/hgrc is not transferred during clones, so if you "sage -clone ...", the "git" setting is lost for that repo. If people don't work with clones, or if they use the version of Mercurial distributed with Sage, or if they have "git=1" in their own .hgrc file, this won't affect them. I suppose we could rewrite the file in the sage-clone script, but I don't know if it's worth it. Opinions?

For the root repo, my patch works for me. Can someone else check it? Pending opinions on modifying sage-clone, everything else gets a positive review from me.

comment:52 in reply to: ↑ 51 Changed 8 years ago by leif

Replying to jhpalmieri:

One small issue: as you said, .hg/hgrc is not transferred during clones, so if you "sage -clone ...", the "git" setting is lost for that repo. If people don't work with clones, or if they use the version of Mercurial distributed with Sage, or if they have "git=1" in their own .hgrc file, this won't affect them. I suppose we could rewrite the file in the sage-clone script, but I don't know if it's worth it. Opinions?

As this falls into the category of surprising (if not annoying) "features", I'd say sage-clone should then copy it over.

Disclaimer: Doesn't affect me personally. ;-)

Changed 8 years ago by jhpalmieri

scripts repo

comment:53 follow-up: Changed 8 years ago by jhpalmieri

  • Description modified (diff)

Okay, here's a patch to sage-clone which appends "git=true" to devel/sage/.hg/hgrc.

comment:54 in reply to: ↑ 53 ; follow-ups: Changed 8 years ago by kcrisman

Replying to jhpalmieri:

Okay, here's a patch to sage-clone which appends "git=true" to devel/sage/.hg/hgrc.

Do I read correctly that the things remaining to review are

  • the patch to the root repo
  • the patch to the sage-clone script

And that we only want to have these have git=True, and not enable queues or add a username or anything like that? It doesn't look like it appends to anything - I thought, based on the above, that this file is created at that time. (Is that, presumably, after devel/sage is changed to point to sage-newbranch?)

Sorry if these questions are dumb, just trying to help get this reviewed.

comment:55 Changed 8 years ago by kcrisman

  • Authors changed from Keshav Kini to Keshav Kini, John Palmieri

comment:56 in reply to: ↑ 54 ; follow-up: Changed 8 years ago by kini

Replying to kcrisman:

Do I read correctly that the things remaining to review are

  • the patch to the root repo

I'll vouch for that (is that allowed?)

  • the patch to the sage-clone script

Looks good to me too, but again, I am a co-author on this ticket.

And that we only want to have these have git=True, and not enable queues or add a username or anything like that? It doesn't look like it appends to anything - I thought, based on the above, that this file is created at that time. (Is that, presumably, after devel/sage is changed to point to sage-newbranch?)

Yes, see this comment. All that extra stuff (besides git=True) is put in the file $SAGE_ROOT/local/etc/mercurial/hgrc by the installer of mercurial-1.8.4.spkg from #10594. Indeed, the file in John's patch to sage-clone could just as well open the .hg/hgrc file with mode 'w' rather than 'a', I think.

comment:57 Changed 8 years ago by kcrisman

  • Reviewers changed from John Palmieri to John Palmieri, Keshav Kini

Yeah, it's okay to review a coauthor's changes as long as you don't review your own changes. There are many tickets where precisely this happens. Otherwise we would never get things reviewed.

Well, either way on the write mode, as long as you review it works.

comment:58 in reply to: ↑ 56 Changed 8 years ago by jhpalmieri

Replying to kini:

Yes, see this comment. All that extra stuff (besides git=True) is put in the file $SAGE_ROOT/local/etc/mercurial/hgrc by the installer of mercurial-1.8.4.spkg from #10594. Indeed, the file in John's patch to sage-clone could just as well open the .hg/hgrc file with mode 'w' rather than 'a', I think.

Well, when you make a clone, a new .hgrc file is written, saying something like

[paths]
default = .../devel/sage

I'm not sure of the purpose of this, but I thought we should append to it, not overwrite it.

comment:59 in reply to: ↑ 54 Changed 8 years ago by jhpalmieri

Replying to kcrisman:

Replying to jhpalmieri:

Okay, here's a patch to sage-clone which appends "git=true" to devel/sage/.hg/hgrc.

Do I read correctly that the things remaining to review are

  • the patch to the root repo
  • the patch to the sage-clone script

That's right, I gave a positive review to everything else. Since I wrote those two, anyone else can review them.

comment:60 Changed 8 years ago by kcrisman

  • Status changed from needs_review to positive_review

Well, Keshav just did!

comment:61 Changed 8 years ago by jdemeyer

  • Dependencies set to #10594
  • Description modified (diff)

comment:62 Changed 8 years ago by jdemeyer

  • Merged in set to sage-4.7.2.alpha2
  • Resolution set to fixed
  • Status changed from positive_review to closed

Changed 8 years ago by jdemeyer

Same as trac_11121-hgrc.local-bin.patch but keeping the file mode 0755

comment:63 Changed 8 years ago by jdemeyer

  • Description modified (diff)
Note: See TracTickets for help on using tickets.