[00:03] <mgz> http://retout.co.uk/blog/2010/11/03/gnash_from_git <- there was really no prospect of progress on savannah?
[00:09] <mgz> losing: your earlier problem is bug 632704 perhaps?
[00:11] <peitschie> mgz: I thought they were getting help with savannah... any idea wats stalled?
[00:12] <mgz> nope. will poke through the mailinglist archives see what's been said.
[00:15] <losing> mgz: yep, you are correct
[00:15] <mgz> peitschie: from January -> https://lists.ubuntu.com/archives/bazaar/2010q1/066291.html
[00:16] <jbowtie> Strange. Just added support for checking out TFS branches, but bzr info shows me that I created a standalone tree instead of a checkout.
[00:16] <mgz> losing: metoo it, vila may be interested
[00:18] <losing> mgz: not sure what you mean.  Do you want me to add a comment with some useful details?
[00:18] <mgz> well, if you have any that would be good. I just meant doing <https://bugs.launchpad.net/bzr/+bug/632704/+affectsmetoo>
[00:19] <peitschie> mgz: thats what I remembered seeing as well...so it seems  that the move to bzr+ssh has stalled somewhat... sftp would definitely be slow as 3-day old porridge...
[00:19] <jbowtie> Maybe I'm missing some implementation for bind?
[00:19] <losing> gotcha
[00:22] <mgz> not an area I've looked at I'm afraid jbowtie, you probably need jelmer if you get really stuck.
[00:22] <peitschie> mgz: http://savannah.gnu.org/support/?107077
[00:22] <peitschie> mgz: (links to the discussion threads are down so I cant see what's progressed since march this year)
[00:24] <jbowtie> mgz: It's good, I'm just walking myself through the code path for bind() to see if I'm missing any implementation.
[00:25] <pifantastic> Today is not my day.  Just got the following error after committing to launchpad: http://pastie.org/1271091
[00:25] <pifantastic> that commit hasnt shown up yet on launchpad
[00:27] <pifantastic> I think it may be lost in the ether
[00:28] <mgz> what fun.
[00:28] <mgz> bug 304545 may be related.
[00:29] <mgz> diagnosis. suggests just trying again may work.
[00:29] <pifantastic> trying again gave me a TooManyConcurrentRequests error
[00:30] <pifantastic> I wonder if I could merge back and try and recommit
[00:30] <mgz> ha. probably need to wait for the last process to give up.
[00:30] <mgz> I'd file a new bug against launchpad-code with your traceback.
[00:31] <pifantastic> in the mean time, where is my commit? :P
[00:31] <pifantastic> im not sure how to recover it so I can try again
[00:31] <mgz> safely on your drive, thanks to the wonders of dvcs.
[00:32] <pifantastic> good point :)
[00:33] <pifantastic> good heavens, now getting Server denied check_authentication  from launchpad
[00:33] <pifantastic> I think im going to step away
[00:35] <pifantastic> ah there we go
[00:35] <pifantastic> commit looks find on lp
[00:35] <pifantastic> Im guessing the error was in the XML returned from lp after the request
[00:35] <pifantastic> maybe a malformed response
[00:37] <peitschie> pifantastic: you really pissed off some computer god somewhere i think!
[00:37] <pifantastic> it's been one of those days
[00:41] <jbowtie> Hmm. bzr.bind fails silently.
[00:42] <jbowtie> I would expect it to write something to branch.conf (bound_location=xxx)
[00:42] <spiv> jbowtie: :(
[00:43] <jbowtie> Oh, I'm not setting self.base in my __init__
[00:45] <jelmer> jbowtie: have you tried running the ControlDir tests against the tfs control dir implementation?
[00:45] <jbowtie> And branch.set_bound_location just swallows the exception, apparently by design.
[00:46] <jbowtie> jelmer: I've only just started hooking the implementations to the various test suites; clearly I need to accelerate that.
[00:48] <jbowtie> jelmer: checkout/bind/unbind was really the last piece I wanted to implement before the big testing push.
[00:49] <jbowtie> Now I have some confidence that implementation is far enough along to be worth the testing/refactoring cycle.
[00:55] <jbowtie> Yay, checkout/bind/unbind works!  Now on to hooking up the all the tests!
[01:25] <jbowtie> "No module named layout.test_custom" running bzr selftest, any clues?
[01:27] <jbowtie> nvm, it's a missing directory error I reported on the mailing list back when.
[01:37] <glyph> Hey
[01:37] <glyph> If I do some commits on a machine where I forgot to do 'bzr whoami'
[01:37] <glyph> is there a way to edit history to change the revision author?
[01:37] <beuno> glyph, there is not
[01:38] <glyph> wow, really?
[01:38] <glyph> is there a way to edit log messages?
[01:38] <mwhudson> no
[01:38] <mwhudson> well, you can fix both things by rebasing of course
[01:38] <glyph> mwhudson: rebasing, or at least the rewrite plugin, doesn't seem to be sufficient
[01:39] <glyph> it remembers the (wrong) author and introduces a distinct 'committer' field
[01:39] <mwhudson> well, "some kind of rebasey operation"
[01:39] <glyph> plus there is no way to edit log messages as you rebase
[01:43] <spiv> glyph: in principle rebasing is the only way to do that, it may be the bzr-rewrite plugin is a bit lacking here though.
[01:44] <glyph> spiv: Yeah.  I'm fine with rebasing
[01:44] <spiv> You could use (abuse?) bzr-fastimport for this, it has tools for filtering/editing the exported revs.
[01:45] <glyph> Basically I just want an easier way than copying patches to just do 'bzr uncommit; bzr uncommit; bzr uncommit; bzr ci; bzr ci; bzr ci;'
[01:45] <glyph> spiv: I confess I've never really understood the purpose of fastimport
[01:46] <glyph> in particular, I don't understand why bzr-svn isn't just fast by itself and it needs a whole other plugin to help it along
[01:46] <spiv> glyph: fastimport isn't especially related to svn
[01:47] <spiv> glyph: it's a reasonable request, and I think the rewrite plugin ought to accomodate it.
[01:50] <spiv> (after all, the rebase plugin clearly already has most of the infrastructure required)
[01:52] <spiv> glyph: tell you what, I think I can see a half-baked way to hack this into bzr-rewrite, give me a few minutes and let's see...
[01:54] <spiv> glyph: to be clear, you want to take revisions that say 'committer: Foo' and rewrite them to say 'committer: Bar'?
[01:56] <glyph> spiv: author: Foo to author: Bar, actually
[01:56] <glyph> spiv: but yeah, that's the general idea.
[01:58] <spiv> glyph: and leave the committer: alone?
[01:58] <glyph> spiv: the committer: too
[01:58] <glyph> spiv: basically it's a machine where somehow my 'bzr whois' somehow got to be 'glyph@localhost'
[01:59] <glyph> but I am generally interested in rewriting / cleaning up history
[01:59] <spiv> Ok, so it's rewrite 'glyph@localhost' anywhere it appears in committer/authors.
[01:59] <lifeless> spiv: I would love for someone to turn my manifesto into a reality; I think it would meet a missing 'must have' component for bzr in a tasteful way :)
[02:00] <spiv> lifeless: yes, it would be nice.
[02:00] <glyph> lifeless: which manifesto is this?
[02:00] <lifeless> glyph: history editing support
[02:00] <glyph> lifeless: oh.  Yes, that would be great.
[02:00] <lifeless> glyph: theres a cultural knee-jerk against it in bzr-land, which I tried to inject reason into.
[02:01] <glyph> lifeless: you know what would be really extra great, would be integrating it into 'bzr qlog' (or a tool like it) so that revisions which have been pushed show up in a different color than ones which haven't
[02:02] <lifeless> http://osdir.com/ml/bazaar/2009-06/msg00338.html
[02:03] <glyph> lifeless: One use-case you don't talk about in there is the 'open source prep-work' case
[02:06] <glyph> I have a proprietary repository, it has a bunch of proprietary crud in it, I start working on open sourcing it, and I need to delete the revisions which contain large proprietary opaque blobs, but I don't want to lose _all_ the history
[02:07] <spiv> glyph: fastexport is currently an ok way to do that, IIRC.
[02:07] <lifeless> glyph: that's covered really
[02:08] <glyph> spiv: OK, good to know.
[02:08] <glyph> spiv: where's the documentation for fastimport?
[02:08] <lifeless> glyph: once you break the history chain, its a rewrite edit full stop - in any system
[02:08] <glyph> lifeless: Yeah, I'm aware of that :)
[02:08] <lifeless> glyph: and thus that use case is covered?
[02:09] <glyph> lifeless: uh, I don't think so?  at least, *I* don't know how to do it with fastimport
[02:10] <lifeless> glyph: so, I was saying in that doc - 'these are things we need to support'
[02:11] <glyph> lifeless: anyway, the other use-case that I have is ... it's not really a direct use-case in a sense
[02:11] <glyph> I am having trouble expressing it
[02:11] <glyph> basically it's editing unpushed stuff
[02:11] <lifeless> glyph: so use case being covered means : 'if the mythical software in that doc exists, what you want to do would be doable'
[02:11] <glyph> lifeless: oh!
[02:11] <glyph> lifeless: yes, absolutely
[02:11] <glyph> lifeless: your proposal there covers the use-case completely, i'm just saying it's a very strong motivation to _do_ those things :)
[02:12] <lifeless> editing unpushed stuff - thats a simple case of history-polishing + patch-management
[02:16] <glyph> lifeless: Yes.. I don't have any unique requirements there either
[02:16] <glyph> Just an observation
[02:17] <lifeless> sure :)
[02:17] <lifeless> You are right that I didn't directly talk about that combo
[02:17] <lifeless> I think that I didn't because its generally known to be 'ok' - when folk are not collaborating on stuff
[02:17] <lifeless> as in, its trivially ok to do destructive local edits
[02:18] <glyph> The best way to describe my personal experience is to say that there is a sliding scale of how 'serious' a VCS commit is
[02:18] <lifeless> 'uncommit' comes to mind
[02:18] <spiv> glyph: lp:~spiv/bzr-rewrite/rewrite-committer-hack.  It's completely untested beyond looking at pyflakes output.
[02:18] <lifeless> spiv: theres an older one for committer that I did
[02:18] <glyph> spiv: You the man.
[02:18] <spiv> lifeless: heh.
[02:18] <lifeless> spiv: jelmer hasn't merged it :(
[02:18] <spiv> glyph: it might be worth looking at lifeless' branch!
[02:19] <glyph> lifeless: More serious == worse
[02:19] <spiv> Ah well, time spent getting some familiarity with bzr-rewrite was probably time well spent anyway.
[02:19] <glyph> The most serious kind of commit is to a CVS repository
[02:19] <lifeless> glyph: -lol-
[02:20] <glyph> Because your change gets mangled and basically lost, and HEAD becomes the truth for real
[02:20] <lifeless> modern CVS has atomic commits
[02:20] <lifeless> fwiw
[02:20] <lifeless> with uuids
[02:21] <spiv> glyph: I'm almost certain lifeless' branch will be more sensible than my hack, which really is a hack.  lp:~lifeless/bzr-rewrite/dev
[02:21] <glyph> Second is svn; you can undo commits since they're atomic, and you can put stuff in branches, but it's still instantly public
[02:22] <glyph> bzr is not very serious at all, largely because of the convenience of uncommit and rebase
[02:23] <lifeless> spiv: I wouldn't underestimate the value of a hack ;)
[02:24] <glyph> I can save a change knowing that is easy to undo it, or merge it, or reverse it ( I discovered the 'reverse cherry pick' menu item in qlog today and it is awesome)
[02:24] <glyph> The direct consequence of this is that I commit MUCH more often
[02:25] <spiv> \o/
[02:26] <glyph> In particular, I typically commit before running tests, rather than after
[02:26] <glyph> Which means that my whole development workflow is streamlined
[02:28] <glyph> Anyway... If there were a good ui for editing unpunished history, I would probably just hook up a 'bzr commit' script to run after 'save' in my editor
[02:28] <glyph> Unpushed, even.
[02:30] <glyph> Having to think of a good descriptive change message *before* bzr will agree to save my work is the #1 thing keeping me from committing right now
[03:01] <glyph> Is there a way to tell bzr about a default protocol?
[03:01] <glyph> On several of my domain names, the protocol specification is now longer than the domain itself :)
[03:02] <glyph> i.e. 'bzr pull foo/~/bar -> bzr pull bzr+ssh://foo/~/bar'
[03:02] <maxb> protocol specification?
[03:03] <maxb> Well, you could use a small custom plugin to implement certain aliases
[03:03] <peitschie> whats the easiest way to drop into a debug session with python under debian?
[03:03] <maxb> e.g. foo:bar where foo: is a shortcut for bzr+ssh://foo/~/
[03:03] <peitschie> that is, running bzr under debian... drop into a debug python :)
[03:04] <glyph> maxb: Hmm, I guess the launchpad plugin would be a good start for that
[03:04] <glyph> maxb: any pointers as to where the relevant code is?
[03:05] <maxb> glyph: http://paste.ubuntu.com/525434/
[03:05] <maxb> That's what I have in my ~/.bazaar/plugins/
[03:06] <maxb> actually come to think of it there's nothing special about the colon there, so you could alias foo/ if you wanted to, I guess
[03:06] <maxb> it might be more confusable, though
[03:08] <glyph> maxb: wow.  just that, in ~/.bazaar/plugins/something.py?
[03:08] <glyph> I think I'll stick with a colon, don't want to do anything _too_ weird.
[03:12] <maxb> yep
[03:29] <jbowtie> Anyone know what this is about?  http://theironlion.net/blog/2010/11/03/favor-ask-everyday-bazaar-users/
[03:30] <jbowtie> I'm intrigued by the promise not to be evil.
[03:30] <peitschie> ahh... found it... kill -s SIGQUIT <bzr pid>
[03:39] <jbowtie> Am I supposed to be seeing curl connection errors when running 'bzr selftest'?  (on Ubuntu if that makes a difference)
[04:01] <spiv> peitschie: typically Ctrl-\ sends SIGQUIT to the currently foregrounded process
[04:01] <peitschie> spiv: woah!  way easier :D.  Thanks!
[04:02] <peitschie> now if only I could figure out why bzr/python suddenly has started hanging on os.access calls.....
[04:04] <spiv> jbowtie: supposed to?  No.  IIRC there may be some known flakiness with those tests... vila would remember the details.
[04:08] <jbowtie> spiv: FAILED (failures=8, errors=52, known_failure_count=48)
[04:09] <jbowtie> spiv: Some of those are due to my plugin (so sort of expected) but most of them seemed to be due to pycurl throwing exceptions on https connections.
[04:13] <jbowtie> Gah. Can't read test output, will have to re-run the suite with a redirection in place to capture it. That's another hour of my life.
[04:19] <spiv> jbowtie: if you have a multicore system then try adding --parallel=fork
[04:22] <jbowtie> spiv: Will do when I get home. Think I'm passing all the per_foreign_vcs repository tests now.
[04:26] <lifeless> jbowtie: thats awesome
[07:05] <spiv> Well, the New bug count is back down into single digits.
[07:05] <spiv> That's EOD for me.
[07:10] <lifeless> nice
[07:39] <vila> hi all !
[07:42] <spiv> vila: Good evening
[07:42] <vila> spiv: hey ! Enjoy !
[07:42] <spiv> vila: would you mind taking a look at https://bugs.launchpad.net/bugs/660935?  It might be a dupe, or something you can easily fix
[07:43] <vila> spiv: I will, conflict resolution is back at the top of my TODO list anyway
[07:44] <vila> ach, no reproducing recipe :-/
[07:51] <spiv> vila: of course not, that would be too easy!
[16:15] <rocky> jelmer, just an fyi, looks like launchpad has bzr-svn 1.0.4 but http://wiki.bazaar.canonical.com/ForeignBranches/Subversion#releases only has 1.0.3 at this point
[16:15] <jelmer> rocky: thanks
[16:15] <jelmer> 1.0.4 is indeed the latest version, I'll update the wiki page
[16:16] <rocky> jelmer, don't suppose it would be worthwhile to just remove the releases section on the wiki page and have it point to the launchpad download section? that way you don't have to maintain multiple references
[16:16] <rocky> jelmer, and update pypi's download link to point to launchpad as well
[16:16] <jelmer> rocky: I don't actually maintain the launchpad download section but it's very good at picking up new releases from http://samba.org/~jelmer/bzr/
[16:16] <jelmer> which is why it's the most reliable source at the moment :-)
[16:17] <rocky> jelmer, well either way, it seems like having to manually update the wiki page is a bad thing and it should just point to the most reliable download source :)
[16:17] <rocky> most reliable download listing, rather
[16:33] <vila> jam: hi
[16:34] <jam> hi vila
[16:34] <vila> jam: aren't you PP this week ?
[16:34] <jam> I'd have to look at the page
[16:35] <jam> looks like it
[16:36] <vila> jam: did you get lp accept your emails again ?
[16:36] <jam> yeah, finally
[16:52] <jam> vila: question for you
[16:52] <jam> "bzr config" doesn't seem to pay attention to "policy:appendpath" is that intentional?
[16:52] <jam> vila: http://paste.ubuntu.com/525769/
[16:54] <vila> jam: hmm, that's a good question...
[16:54] <jam> And I think you already know about the bug w/ "bzr config push" not showing anything but "bzr config location" showing all *_location
[16:55] <jam> http://paste.ubuntu.com/525771/
[16:55] <vila> I can find arguments both ways
[16:55] <jam> I thought I saw a bug from spiv about that one
[16:55] <vila> push != *push* ?
[16:55] <jam> vila: but location != "*location"
[16:55] <jam> or IMO shouldn't be
[16:56] <jam> if you aren't going to make it a general match, it shouldn't be a substring match at all
[16:56] <jam> it is currently a 'tail' match which is a bit odd
[16:56] <vila> that's a weird fnmatch side-effect anyway
[16:57] <vila> hmm, or may be it's a search/match bug
[16:58] <jam> vila: so you are using "search" which means find it as a substring, but fnmatch is turning it into a "foo$" style search
[16:59] <jam> if you want *path* != path, then you should use "matching_re.match()" and not "search"
[16:59] <jam> (and probably manually add $ at the end, because otherwise path == path*, while right now path == *path which IMO is much worse than either of the other options)
[17:06] <jam> mgz: any chance you could update the review on https://code.edge.launchpad.net/~doxxx/bzr/mergetools/+merge/38663
[17:06] <jam> I now poolie is on vacation this week
[17:06] <jam> know
[17:15] <jam> mgz: also, what's up with the testtools 0.9.5 stuff? do you know vila?
[17:15] <jam> do we have 0.9.5 on pqm yet?
[17:15] <vila> we still don't have it AFAIK :-/
[17:16] <mgz> jam: he's covered most of the things I raised... except the non-ascii problem, which he's struggling to test because that's all screwed... which is blocked on pqm updating testtools :)
[17:16] <vila> but 0.9.7 is out too I think
[17:16] <jam> vila: yeah, I just checked your rt, and it looks blocked on having a .deb file, and that is blocked on backporting to hardy
[17:17] <jam> which we can't upgrade because we want to support py2.4
[17:17] <jam> which I personally want to keep until RHEL6 is out
[17:17] <jam> at which point, everyone has at least an upgrade story, so I don't care anymore
[17:17] <jam> though keeping 2.0/1/2 py2.4 compatible would be nice
[17:18] <jam> mgz: I thought *successful* tests with non-ascii work, just when they fail they spew garbage at you
[17:18] <mgz> generally, but that makes developing a decent test hard.
[17:18] <jam> mgz: https://code.edge.launchpad.net/~gz/bzr/escape_selftest_console_output_633216/+merge/34890
[17:19] <jam> that's also blocked on the 0.9.5 stuff?
[17:19] <mgz> is that rt thing just a process failure? can install testtools the normal way for 2.4 no problem
[17:19] <jam> (note that *I* only have 0.9.3)
[17:19] <mgz> try running the test that branch adds then.
[17:19] <jam> mgz: sys admins don't like to install anything without apt
[17:20] <jam> since it makes system management quickly get out of hand
[17:20] <jam> at least, AIUI, we could ask a l-o-s-a t o be sure
[17:20] <mgz> okay, so it's blocked on lifeless? can't we have some less busy person handle that?
[17:21] <jam> mgz: well, jml is also involved in testtools
[17:21] <mgz> it's not hard (he says, largely in ignorance) to debianise a python package
[17:21] <jam> I'm not sure if they realize it is blocked
[17:21] <jml> mgz: I'm working on it in my copious spare time
[17:21] <jam> mgz: also, you commented on https://code.edge.launchpad.net/~ryorke/bzr/140563-optparse-barfs-on-unicode/+merge/39222
[17:21] <mgz> jml is hardly idle either.
[17:21] <jam> any chance for a follow up, he seems to have added more work
[17:22] <vila> jml: ha ! finally ! :-P
[17:22] <mgz> ah, I wish lp would tell you when that happens, can forget to check back otherwise.
[17:22] <jml> actually, I'm not working on it. sorry.
[17:22] <jam> mgz: it is meant to happen via switching WIP => Needs Review
[17:22] <jml> what I'm working on is daily builds of testtools
 vila: yeah, I just checked your rt, and it looks blocked on having a .deb file, and that is blocked on backporting to hardy
[17:22] <maxb> What's wrong with the one in the ~bzr PPA?
[17:23] <jam> maxb: just saw that on the rt as well
[17:23] <mgz> okay, rorryy's change looks good now. I'll follow up on both those reviews... and try and get some of my own bits progressing too.
[17:23] <jam> looks like the discussion got side-tracked and nobody realized we had a possible solution already
[17:23] <jam> mgz: overall, don't fret too much. You've been doing great with reviews. I'm only poking here because I would have to start the review from scratch
[17:24] <jam> so if you know what's up, it is a bit smoother
[17:24] <vila> jam: I'm about to EOD, but thanks for the feedback about config, could you turn your pastebins into a bug so I don't forget ?
[17:25] <mgz> Gordan's branch will want another thorough review, but perhaps poolie will continue on it when he gets back
[17:25] <vila> jam: and do you know where poolie is ?
[17:25] <jam> vila: poolie is on vacation in Disney World this week
[17:26] <vila> oh, ok, I missed that
[17:26] <jam> I don't remember an email
[17:26] <jam> but he certainly told me in person last week
[17:26] <vila> ok
[17:28] <jam> vila: bug #670251 is already my basic bug
[17:28] <mgz> there was a very similar bug with qbzr on that
[17:28] <mgz> the fix was adding '*' to the input string.
[17:29] <mgz> fnmatch.translate behaviour changed at some point.
[17:29] <vila> jam: meh... I didn't see this one...wth ?
[17:29] <jam> mgz: well you could obviously always add "foo*" :)
[17:30] <mgz> woho! my lazr.restfulclient mp just got approved.
[17:31] <vila> I'll blame my perl background here, such bugs are... unexpected :)
[17:32] <vila> ouch, bunch of bug mails ignored for... unknown reason :-/
[17:34] <mgz> bug 575338
[17:35] <mgz> hm, not exactly the same, but the same approach for the fix would work.
[17:35] <jam> vila: bug #671050 is the one about "policy:appendpath" not working correctly
[17:36] <vila> kthk
[17:37] <jam> vila: go be with your family now. :)
[17:40] <vila> almost there :)
[17:41] <vila> just one last selftest run ;)
[17:41] <vila> to fix a bug that will allow me to fix a bug that will allow me resume working on conflict resolution ;)
[19:20] <TresEquis> anybody here up to speed on the setuptools bzr plugin?
[19:26] <roryy> mgz: hrm.  sorry about the spacing etc.  i moan enough about it in C code at others
[19:28] <mgz> no worries roryy :)
[19:28] <mgz> also, PEP 257 talks about always using triple quoted docstrings
[19:29] <mgz> just to take the trivia even further.
[19:30] <roryy> i think i've at least read pep 8, even if it was a while back.  never heard of 257
[19:30] <mgz> when I'm reduced to formatting nitpicks, you must be on the right track.
[19:32] <roryy> cool.  thanks for the review.  bed-time for me!
[19:32] <mgz> night!
[19:38] <cody-somerville> How can you make a pack file smaller?
[19:40] <james_w> delete half the file?
[19:42] <james_w> (not guaranteed to keep all of your data)
[19:44] <mgz> `bzr pack` redoes the repo (and will happen periodically anyway), but if you've committed giant binary files in the past you may be reduced to rewriting history to get sane pack sizes
[21:35] <peitschie> mornin all :)
[22:54] <spiv> vila: I don't think 'bzr config' should use fnmatch.  jam's right, I did file a bug two days ago.
[23:28] <doug> huloo
[23:28] <doug> i want to claw back the last commit, add some more changes to it, and then commit the whole bundle...
[23:28] <doug> there an easy trick for that?
[23:28] <fullermd> uncommit?
[23:28] <doug> that simple, huh
[23:29] <fullermd> As long as nobody else has had a chance to get a hold of that revision, yah.
[23:29] <doug> coolio
[23:29] <doug> i was worried because of the message it gives
[23:29] <doug> "The above revision(s) will be removed"
[23:29] <fullermd> uncommit backs you up to the state right before you ran 'commit', so you'll wind up with a bunch of pending changes.
[23:29] <doug> as long as that just means repo changes, i'm happy.
[23:29] <fullermd> Well, that's what it does   :)
[23:30] <doug> hm, now it says i can restore the old tip by running the given pull command
[23:30] <doug> that just reverts the uncommit?
[23:31] <fullermd> From 30k feet, yah.
[23:31] <doug> right
[23:33] <doug> fullermd++
[23:33] <doug> thanks
[23:36] <peitschie> did you just get incremented fullermd?!
[23:38] <fullermd> Great, now I have to go punch a new hole in my belt...