Dear all,
I tried different ways of applying a patch and probably made a bit of a
mess in my repository. Is there a way to revert it back to a clean 4.1.1
install? I keep getting a message about an uncommitted merge...
Here is what I did in OSX 10.4:
--
Alex Ghitza wrote:
To Carlo: thanks for updating the wiki on queues, which has grown
since I last looked. I find your solution rather counterintuitive
though: surely ones does "hg -qnew" at the beginning of some work, so
that seems a funny time to write the commit message?
John Cremona wrote:
> Somehow, reading both the mercurial queues manual and the sage wiki
> version of the same, there were still things not understood (by me)!
Of course, the obvious request now is to ask you to update the sage wiki
so that you would have understood it :).
Jason
--~--~
> > It is worth pointing out that if one uses
>
> > hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
>
> > it is MUCH easier to remove the patch after you test it. That means
> > no more needing to make a new clone for each test, and allows people
> > like me to avoid using queu
OK, I understand now. There are two different points being made:
(1) adding -e to the qnew command pops up an editor for you to enter a
commit message; so does adding -e to a qrefresh command, so you can
update that message later.
(2) normally qnew will abort if it finds any modifications. Bu
John Cremona wrote:
> To Carlo: thanks for updating the wiki on queues, which has grown
> since I last looked. I find your solution rather counterintuitive
> though: surely ones does "hg -qnew" at the beginning of some work, so
> that seems a funny time to write the commit message? But I don'
>>> To Carlo: thanks for updating the wiki on queues, which has grown
>>> since I last looked. I find your solution rather counterintuitive
>>> though: surely ones does "hg -qnew" at the beginning of some work, so
>>> that seems a funny time to write the commit message? But I don't
>>> unders
2009/8/27 Carlo Hamalainen :
>
> On Thu, Aug 27, 2009 at 11:08 AM, John Cremona wrote:
>> To Carlo: thanks for updating the wiki on queues, which has grown
>> since I last looked. I find your solution rather counterintuitive
>> though: surely ones does "hg -qnew" at the beginning of some work,
On Thu, Aug 27, 2009 at 11:08 AM, John Cremona wrote:
> To Carlo: thanks for updating the wiki on queues, which has grown
> since I last looked. I find your solution rather counterintuitive
> though: surely ones does "hg -qnew" at the beginning of some work, so
> that seems a funny time to writ
To Alex: very basic! Although I have occasionally been reduced to
editing patches by hand, surely that should be a last resort!
To Minh: I think this is what I was looking for (hg qrefresh -e). I
had tried hg qrefresh -m "commit message" but it did not work. I will
try this next time.
To Ca
On Thu, Aug 27, 2009 at 10:41 AM, Alex Ghitza wrote:
>
> On Thu, Aug 27, 2009 at 6:30 PM, John Cremona wrote:
>> One reason why I have (temporarily, I expect) stopped using hg queues
>> was that it was pointed out to me that the patches I made from there
>> (hg export qtip) did not have a proper c
Hi John,
On Thu, Aug 27, 2009 at 6:30 PM, John Cremona wrote:
> One reason why I have (temporarily, I expect) stopped using hg queues
> was that it was pointed out to me that the patches I made from there
> (hg export qtip) did not have a proper commit message.
The person who pointed that out
On Thu, Aug 27, 2009 at 6:30 PM, John Cremona wrote:
> One reason why I have (temporarily, I expect) stopped using hg queues
> was that it was pointed out to me that the patches I made from there
> (hg export qtip) did not have a proper commit message. I read all the
> documentation, did what it
Thanks for all the replies. OK, Nils, within seconds of asking that
question I knew that the answer was "check the documentation" and did
so
It never ceases to amaze me how many slightly different ways there are
of doing things, and that we all use slightly different variants!
One reason wh
On Wed, Aug 26, 2009 at 2:09 PM, kcrisman wrote:
>
>
>
> On Aug 26, 11:06 am, David Joyner wrote:
>> The way I do this (which may not be the best way) is
>>
>> 1. cd to the SAGE_ROOT directory
>> 2. ./sage -b main (this assures you are starting from the main
>> branch and not cloning form a cl
On Aug 26, 2:53 pm, John Cremona wrote:
> Interesting -- can you supply more details (and or a reference)?
>
> I have used hg_sage.apply() many times; how does import_patch() differ?
>
I can. And so can you :-)
sage: hg_sage.apply?
Type: instancemethod
Base Class:
String Form:
2009/8/26 kcrisman :
>
> It is worth pointing out that if one uses
>
> hg_sage.import_patch("/path/.../blah.patch",options="--no-commit")
>
> it is MUCH easier to remove the patch after you test it. That means
> no more needing to make a new clone for each test, and allows people
> like me to avo
On Aug 26, 11:06 am, David Joyner wrote:
> The way I do this (which may not be the best way) is
>
> 1. cd to the SAGE_ROOT directory
> 2. ./sage -b main(this assures you are starting from the main
> branch and not cloning form a clone)
> 3. ./sage -clone ABCDx (where ABCD is the trac number
The way I do this (which may not be the best way) is
1. cd to the SAGE_ROOT directory
2. ./sage -b main(this assures you are starting from the main
branch and not cloning form a clone)
3. ./sage -clone ABCDx (where ABCD is the trac number you are
applying the patch from and x=a for the first
On Wed, Aug 26, 2009 at 1:19 PM, J. Cooley wrote:
> I would like to apply the patches from ticket #6384 to the clone I'm
> using. I have not done this before and I want to make sure that I
> apply it to the clone and not the main. I'm not entirely sure how to
> do this.
>
> Also, this patch seems
Jenny, I'll show you how to do this today.
[To the list: Jenny is an undergraduate working with me for a few
weeks on a project implementing some elliptic curve things in Sage.
Obviously I'm showing her how to use Sage, but I've been very busy
with other stuff lately so she is also getting help f
21 matches
Mail list logo
