=== davecheney is now known as davecheney95 [06:10] wallyworld: /wave, how's it going today? [06:11] hi, going well. going to put up a mp soon. i have all tests except one working (but that fails in trunk also). i keep finding more refactoring to do but will draw the line so i can get something merged in. next thing to do is add a lot of missing tests [06:13] wallyworld: sounds good. I fully support ratcheting the changes into trunk as much as possible. [06:14] yeah, i don't want to make it perfect but i also don't want to have duplicated code blocks and such. so it will be fairly clean [06:14] i'm wishing Go had infrastructure for IOC and such [06:15] this is the type of project hat would really benefit from those patterns [06:23] wallyworld: isn't that what interfaces are for? [06:23] sure, but you need an infrastructure to cleanly to the dependency injection [06:24] eg Spring in the Java world [07:01] Morning === Guest84948 is now known as rogpeppe === rogpeppe is now known as rogpeppe1 === rogpeppe1 is now known as rogpeppe2 === rogpeppe2 is now known as rogpeppe3 === rogpeppe3 is now known as rogpeppe [07:40] mornin' all [07:40] rogpeppe: Hiya. [07:45] Iiirks! [07:45] My test just stopped my VM. [07:55] hey all [07:57] fwereade__: Morning. [07:58] davecheney95: sorry about trunk breakage. looks like i hadn't broken a test in the right way before checking that it passed. [07:58] davecheney95: will fix asap [07:59] fwereade__: hiya [08:00] rogpeppe: it's not broken per 'se [08:00] davecheney95: it is! [08:00] i just copied some of the other cert files that juju generated into the right place and it worked fine [08:01] davecheney95: it's quite badly broken [08:01] davecheney95: i've got some code that generates cert and key in a single file, but the new config stuff expects it in two [08:01] rogpeppe: orly; [08:02] i got it to work with only one [08:02] davecheney95: i thought it was ok 'cos my tests would've caught a problem, but it was masked [08:02] anyhoo: flick me a CL and i'll give it a review [08:02] file stuff on disk is hard [08:02] davecheney95: yeah, it'll work if the cert is already there [08:03] davecheney95: it's just these big changes - i've got quite a bit up in the air currently [08:03] rogpeppe: yup, that is what I did, i copied a pem file that juju generated from a previos revision into the right place and it worked [08:03] which was promising [08:03] davecheney95: hopefully it'll all be reconciled soon - the CL will be a temporary patch before the code goes away [08:03] * davecheney95 is uncomfortable about the cheques we're writiing for the juju tool to do as a setup agent [08:04] * davecheney95 proposes a new command, juju setup [08:04] which is also run by default in some situatoins [08:06] Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaargh! [08:06] ErrorSitsInFrontOfTheScreenException [08:06] *ashamed* [08:06] -EFACEPALM ? [08:07] davecheney95: Exactly! *grmblx* [08:07] Too dumb to use a self written command correct. [08:17] jam: i need a little bzr advice. i have ditched my usual co-location workflow and directory layout to try cobzr. i have set in location.conf "public_branch:policy = appendpath" but this causes .bzr/cobzr to appear in the branch paths. what's the correct config? [08:18] wallyworld: I don't use cobzr, so I can't say for sure. One option is to use 'appendpath' but set the containing location to include .bzr/cobzr [08:18] So instead of [/path/to/branches] you use [/path/to/branches/.bzr/cobzr] [08:18] wallyworld: I think abentley worked on a 'just take the last name' rather than appendpath [08:18] ah ok, will try thanks. i should have just stuck to what worked :-) [08:18] but I don't remember how that ended up. [08:19] ok [08:19] Also, you might try something with nick, let me look at the code abit. [08:19] wallyworld: just to mention, I just use a lightweight checkout pointing to my normal locations for branches. [08:19] which gives you the same functionality as cobzr, but the branches don't exist in a subdir. [08:20] yes, that's what i normally do too [08:20] i think i'll ditch cobzr and revert to that [08:22] jam: actually, your idea aboce to add .bzr/cobzr to the containing locations seems to work [08:23] davecheney95: are you talking about the certificate generation stuff? [08:24] davecheney95: (which, BTW is more broken than i realised, dammit - the fix isn't quite as trivial as i want) [08:25] wallyworld: FWIW i use cobzr but i've never touched location.conf AFAIR [08:25] rogpeppe: all i can say is what was in the email [08:25] i went to use a environment i hadn't used about 10 revisions ago [08:25] and it whinged that I didn't have the magic certificate poop [08:25] rogpeppe: i use to to save me typing the full urls each time i push etc [08:25] davecheney95: that's because i broke it, not necessarily because it's fundamentally the wrong design [08:26] wallyworld: ah, that sounds useful actually [08:26] rogpeppe: it's quite awesome. i just type "bzr push" and it knows what to do [08:27] i can pastebin my relevant config if you like [08:27] davecheney95: that happens for me too - i just rely on lbox to work out where it wants to push to, then it remembers is [08:27] it [08:27] wallyworld: please [08:27] ok, sec [08:27] wallyworld: that 2nd last remark should've been addressed to you. [08:28] ok. i'm just trying lbox now for the first time [08:28] davecheney95: BTW the certificate generation stuff is moving from the juju package to the environs package [08:28] why don't we use lp for mps? isn't that the company standard? did we get an exception? [08:29] wallyworld: we do [08:29] wallyworld: but we use codereview too [08:29] wallyworld: because it's considerably awesomer :-) [08:29] ok, i'm still ramping up on juju processes [08:29] wallyworld: i should have mention, ping me if you need help in your timezone [08:29] i'll see real soon now what's it's like :-) [08:29] davecheney95: thanks, will do [08:29] your timezone is like my timezone, except we're not scared of confusing the livestock [08:30] * wallyworld wishes we had daylight saving [08:30] * davecheney95 wishes we didn't [08:30] lol [08:30] wallyworld: really? The 2h time shift with the rest of the world tends to be very disruptive [08:30] i'm already getting grief about the tuesday meeting 'cos it's slipped to 11pm [08:30] poolie had it, and it was quite annoying [08:30] it's great to get 2 hours more with the yanks [08:30] davecheney95: what time is it for you now? [08:30] excepting collaboration, i really like it [08:31] 19:30 [08:31] 18:30 for me [08:31] when I worked at the trading company, daylight saving sucked [08:31] we had to work til 9pm to cover the indian market [08:31] it makes it really nice for family time at the end of the day [08:32] wallyworld: which part of brisvegas are you in ? [08:32] fig tree pocket [08:32] western suburbs [08:32] you? [08:32] wallyworld: latte sipping inner west sydney [08:32] bondi? [08:33] oh, that's east [08:33] balmain maybe [08:33] i don't know sydney that well [08:33] ashfield, almost the same [08:33] bit further south from the river [08:34] davecheney95: hmm, good thing you can work a bit late often, 'cos otherwise our working days have no overlap at all, unless i get up at 6.30am [08:35] rogpeppe: https://pastebin.canonical.com/78813/ - i just have it set up for goose right now. i could promote the common config items like public_branch:policy to a [/home/ian/juju] section [08:35] when i add juju-core or other projects [08:36] so now bzr info gives: [08:36] Related branches: [08:36] public branch: bzr+ssh://bazaar.launchpad.net/~wallyworld/goose/client-using-identity [08:36] push branch: bzr+ssh://bazaar.launchpad.net/~wallyworld/goose/client-using-identity [08:36] parent branch: .bzr/cobzr/master [08:36] submit branch: bzr+ssh://bazaar.launchpad.net/~gophers/goose/trunk [08:36] so stuff it cares about is set correctly [08:36] wallyworld: cool, thanks [08:37] np [08:37] wallyworld: and you put that in ~/.bzr/locations.conf ? [08:37] ~/.bazaar [08:37] locations.conf [08:38] ha, that's funny [08:39] i did actually set up a locations.conf file once [08:39] rogpeppe: in the non-go world, I have all of my branches roughly mirroring launchpad as: ~/dev/$PROJECT/$BRANCH, which lets me set a policy like the one above, except it works across all of my projects, rather than configuring each one. [08:39] jam: yeah, i did have that setup originally [08:40] jam: my current locations.conf has a push_location of lp:~rogpeppe/ensemble :-) [08:40] that sounds like it has been a while :) [08:40] jam: blast from the past [08:43] save me looking up docs, if lbox says gofmt is sad, do i have to run gofmt against each file individually, or do we have a tool to them all at once? [08:44] wallyworld: in the root juju directory, run "go fmt ./..." [08:44] cool, thanks [08:44] wallyworld: or, from any directory, run "go fmt launchpad.net/juju-core/..." [08:44] i was typing gofmt [08:45] wallyworld: or to do it in the current directory only, run "go fmt" [08:45] worked, thanks [08:45] i didn't appreciate the difference between gofmt and go fmt [08:45] wallyworld: (the go command always uses the package in the current directory by default) [08:45] ok [08:45] wallyworld: gofmt allows access to a few features that go fmt doesn't [08:46] wallyworld: for example the -r flag (which can be awesome BTW) [08:46] wallyworld: go fmt does actually just call gofmt, i think [08:46] gofmt seemed to print the file to stdout [08:46] files [08:46] wallyworld: yeah, that's the default. although you can use gofmt -w too [08:47] iw works with ./... ? [08:47] -w [08:47] wallyworld: no. [08:47] wallyworld: I'm pretty sure gofmt doesn't support './...' but 'go fmt' does [08:47] ok, thanks [08:47] wallyworld: the go tool is the one that understands package wildcards etc [08:48] wallyworld: gofmt just knows about files [08:48] wallyworld: i almost always use go fmt [08:48] ok [08:48] wallyworld: except when i'm editing - then i'll often pipe a section of a file (or the whole thing) through gofmt [08:49] i might look at setting up my IDE to use it in the background [08:49] i already have code inspections but not fully go fmt compliant [08:50] wallyworld: for instance if you use vim, you can do :1,$!gofmt [08:50] wallyworld: i know various people set their editors up to automatically gofmt on save [08:50] i use Intellij with a golang plugin [08:50] i'll look into it [08:51] rogpeppe: yeah, I tried to set up vim with it, but my simple method meant that every write triggered a reload of the working buffer, shoving me all the way to the top of the file. Loosing my place made it impractical. [08:51] wallyworld: and i'm pretty sure that some people (fwreade__ ?) change tabs to spaces on load, and back to tabs on save. [08:51] i'm just waiting on integrated debugging to be supported. i really miss that from Java and Python [08:51] So instead, I just do "go fmt ./... && go test ./..." so every test run reformats. [08:51] jam: yeah i can see how that might be annoying [08:51] wallyworld: ISTR that gdb works with go code [08:52] i really dislike the use of tabs - everyone i mentioned it to is quite incredulous [08:52] Losing [08:52] *sigh* too easy to get that one wrong [08:52] wallyworld: what don't you like about them? [08:52] i've not used gdb - will have to learn, i rely on my ide [08:53] wallyworld: well, I would guess if gdb works, many ides might use that on the backend. [08:53] yeah, gdb does work (i checked once) but i never use it [08:53] Which means you could have intellij integration earlier than later. [08:53] rogpeppe: i can't quite put it into words easily why i dislike tabs, no other language i know of ides it [08:53] does [08:53] wallyworld: I worked on a project in C/C++ that mandated tabs so that people could configure their preferred indent. [08:54] Most python projects mandate no tabs. [08:54] and Java too [08:54] IME [08:54] wallyworld: i've used tabs for a very long time, so i'm always interested to know why people don't like them [08:54] jam: with python it's understandable, because getting the indentation right is crucial [08:55] rogpeppe: yeah, the main problem in python is that you *can* mix spaces and tabs, and that way lies madness. :) [08:55] wallyworld: i like the fact it's just a single character to type to add or remove a level of indentation [08:55] rogpeppe: i guess because the spacing becomes variable for everyone, depending on their setup [08:55] jam: yeah [08:55] rogpeppe: my IDe does all that - i hit tab and it inserts saces on thre fly [08:55] rogpeppe: sure but I use << >> in vim anyway, so indentation is a simple select and move regardless the characters used to indent. [08:55] and it auto indents according to the code style in use [08:55] wallyworld: yeah - that's a problem if people rely on beautiful code alignment. you can't do that in go though :-) [08:55] so i never type lots of spaces [08:56] rogpeppe: and the preference for tabs = 8 is madness IMO [08:56] way too much [08:56] wallyworld: for python, probably [08:56] wallyworld: don't you need to type a few delete characters to remove a level of indentation [08:56] ? [08:57] nope, IDe does it [08:57] but it could be a million, it just depends what your editor is set too [08:57] rogpeppe: I know vim can be configured to know when you are deleting indent chars vs regular spaces. [08:57] it knows whatr the code style is and handles all that [08:57] However, I use <<, I imagine wally does "shift + tab" [08:57] ISTR doing that in VC in the long distant past. [08:57] Backspace deletes all the white space unti lthe next indentation block [08:58] just like if tabs were used [08:58] wallyworld: i don't think go has a preference for tabstop=8 particular [08:58] y [08:58] ly [08:58] i think i read it somewhere [08:58] but i've crammed a lot of Go docs in the past few days [08:58] wallyworld: personally, i'm a heretic because i use a proportionally spaced font [08:59] wallyworld: so you can always set your tab stop if 8 is too much. Which isn't true if you use spaces. For *me* I just adapt between them. [08:59] really???? [08:59] rogpeppe: there is a slight preference if go fmt ends up aligning something with spaces on a continuation line, etc. [08:59] jam: yeah, but as you said, it may mess with alignment [08:59] I thought, I could be wrong. [08:59] jam: yeah. i don't mind much though. [08:59] wallyworld: occasional mis alignment could be a lot better than constant extra depth for you [08:59] jam: i don't find it affects readability [09:00] rogpeppe: why proportional spaced font? [09:00] wallyworld: but i get more readable text per pixel with a proportionally spaced font [09:00] rogpeppe: does it do fixed width spaces for aligned tables? [09:01] jam: yeah, i can switch trivially if i need to [09:01] jam: aligned tables are pretty rare though [09:01] rogpeppe: except for all of the inline comments in structs :) and `json:content` stuff [09:02] jam: yeah. but the alignment there is just prettification. it doesn't make much difference if it's not aligned. [09:02] jam: unlike a table [09:02] sure [09:03] if i used an equivalent font size in fixed with, i'd see much less code. and i like the way proportionally spaced text looks. [09:03] anyway, excuse me, i need to un-break trunk :-) [09:13] jam: i just ran lbox and it created the lp mp, but i got this error: "error: Failed to send patch set to codereview: diff is empty" [09:14] lp can take a little time to generate the code diff [09:14] how do i send the diff to codereview once lp has calculated it? [09:14] wallyworld: sounds odd, offhand sounds like an incorrect submit branch. [09:14] wallyworld: lbox computes the diff and proposes it for you [09:14] wallyworld: what does "bzr diff --old lp:goose/trunk" print? [09:14] jam: the lp mp says the submit branch is https://code.launchpad.net/~gophers/goose/trunk [09:15] jam: that command prints the diff as expected [09:15] hmm, odd [09:16] wallyworld: what does lbox propose -v print? [09:16] lp also shows the preview diff, let me type the the above and see [09:18] rogpeppe: that time it send the diff to codereview, or so it says. it also marked the mp as neews review since i created initially as wip [09:18] wallyworld: that sounds like it all worked [09:18] wallyworld: did it print a codereview url? [09:18] yeah, i have no idea what happened the first time [09:19] rogpeppe: ah no, my apologies - it still failed: error: Failed to send patch set to codereview: diff is empty [09:19] wallyworld: could you paste the lbox output? [09:20] rogpeppe: https://pastebin.canonical.com/78814/ [09:21] rogpeppe: i have to go and put my son to bed and read him a story, i'll be back in a bit [09:25] wallyworld: Diffing branches for codereview: /home/ian/juju/go/src/launchpad.net/goose => /home/ian/juju/go/src/launchpad.net/goose/.bzr/cobzr/lbox-805004725/lbox [09:25] It looks like lbox is treating your goose checkout as the submit target. [09:25] And doing a diff of the code against itself. [09:25] obviously that is an empty diff. [09:25] I don't know where lbox gets the URL of the branch to diff against. [09:26] I would have thought that would be in .lbox, which uses "propose -cr -for lp:goose" [09:26] Maybe it is looking up something else in your config? [09:26] rogpeppe: do you know where lbox gets the target to diff against? [09:27] jam: it should get it from the -for flag, which in this case is set in .lbox [09:30] jam: it looks like that worked too, but i'm not sure why it changed. [09:34] jam: it looks like the FetchRemote logic is failing somehow [09:35] jam: erm, no it doesn't - it all looks ok to me [09:36] the fact that it is diffing against 'lbox' something makes me think it is fetching the remote branch to a temp location and then trying to diff against it, but it also feels like it might be failing to get the actual files to diff against for some reason. [09:41] jam: hmm, it worked fine for me: https://codereview.appspot.com/6858050 [09:41] except that testservices/identityservice/util.go needed gofmting, which makes me suspicious [09:42] i'm not sure how the lbox check could have succeeded if that branch really was current [09:45] rogpeppe: speaking of gofmt [09:45] there are some small changes, and larger ones coming that make gofmt 1.0 and gofmt 1.1 incompatible [09:46] davecheney95: really? in what way? [09:46] there is a small change already that affects the padding of comments on struct members [09:46] and gri is about to commit a change that makes [09:46] for i := range s { i++ } [09:46] valid [09:47] davecheney95: orly?! [09:47] which is going to upset our .lbox.check hook [09:47] davecheney95: oh, you mean the formatting [09:47] yes [09:47] davecheney95: i thought you meant that you could influence a range variable within the body [09:47] the syntax is not changing, just the canonical format [09:48] davecheney95: i guess we'll have to standardise on 1.0.3 gofmt [09:48] rogpeppe: i agree [09:48] davecheney95: until 1.1 is released [09:48] although it'll be 1.0.2 [09:48] 'cos that is what is in precise or quantal [09:48] davecheney95: same difference, i think [09:48] for this, yes [09:49] davecheney95: only problem is: can we get the tip go tool to use a different gofmt? [09:49] davecheney95: i.e. does it just use the gofmt in $PATH or not? [09:49] rogpeppe: jam: thanks for looking, i'll poke around and see what might be happening. certainly something must be correctly setup since launchpad's mp diff is there ok [09:50] go space format from memory [09:50] for people like me that live on tip [09:50] wallyworld: i did the propose myself, and it worked, except that it required a gofmt, which seems odd [09:50] we could add optoinal support for a GO_1_x path (making up a name) [09:50] hmmm. when i first did it it complained and then i fixed all the issues [09:51] review request: https://codereview.appspot.com/6851081/ [09:51] ^ i think this is gettig pretty resonable [09:51] wallyworld: I should have a review for you in a bit. [09:51] jam: using the lp diff? [09:52] eww [09:53] davecheney95: go fmt just uses gofmt from $PATH, so there's no difficulty chopping and changing if we need to [09:54] wallyworld: yeah, I'm still perfectly comfortable reviewing from LP. [09:54] rogpeppe: nice, I can make that work [09:54] and/or from a raw branch when necesasry. [09:54] \o/ [09:55] I have to go in about 20min, so I'd rather get you a review than nothing today. [09:55] thanks [10:15] wallyworld: review submitted. Probably the start of a conversation, though at this point, we can land what you are comfortable with and iterate from there, rather than iterating pre landing. [10:16] jam: ok, will look. thanks [10:27] davecheney95: you've got a review [10:31] ty [10:31] wallyworld: a tiny comment from me as well, not really a full review (since I did the original code, more or less I don't think will be appropriate to review). [10:32] dimitern: thanks, i'll look after replying to jam's lengthy review [10:32] which i'm doing now [10:33] wallyworld: feel free to blame the initial ugliness on me :) [10:33] prototype code! [10:33] not meant to be perfect [10:33] yeah [10:33] dimitern: there is that one failing test - any idea? [10:33] GetObject? [10:34] yeah [10:34] TestObjects [10:35] wallyworld: not really, I struggled with it a bit, but even though the Put was ok and no error reported, Get returned empty data and also no error... probably a sleep of a few secs is in order - the eventual consistency thing of the cloud [10:36] could be. will be nice to know [10:36] so we can plan around it for other things [10:39] wallyworld: also, it seems you're not yet a member of The Go Language Gophers team and you should be [10:39] ah, haven't checked that. thanks, i'll follow up [10:59] Good morning ladies and gentlemen [11:00] Binjour Monsieur Niemeyer [11:00] s/Binjour/Bonjour/ [11:06] TheMue: Merci beaucoup [11:06] "beaucoup" must be my favorite word in French [11:09] I picture imagined language designers saying "Hey, why don't we just throw a few more letters there, just for the fun of it?" [11:10] niemeyer: yeah, the same applies to irish, scottish and manx :) [11:13] niemeyer: Hehe, indeed, just discovered the number of vowels in "beaucoup". [11:21] dimitern: perhaps you could put your initial commit up for review before we put ian's changes on top? [11:22] niemeyer: yo! [11:22] rogpeppe: Heya [11:22] rogpeppe: well, since it's already in trunk, how can I do this? [11:22] dimitern: hmm, good question. erase trunk and start again? :-) [11:22] rogpeppe: done! :D [11:23] rogpeppe: that's what I meant yesterday by wanting someone to take a look at goose/client/client.go first [11:24] dimitern: yeah, it would be a good idea i think [11:26] rogpeppe: I'd really appreciate if you take a look then [11:26] dimitern: the only problem with starting from scratch is that wallyworld's branch becomes divergent, but i don't think that's too much problem actually. apart from jam's review. gotta start somewhere tho. [11:27] dimitern: will do when i see the CL [11:30] rogpeppe: that does make sense for future, but as this is mostly initial experimental hacking that will get replaced in pretty short order [11:31] mgz: i'm not sure. it looks to me like the core of something that will shortly be expanded, with no time to go back to get the core right. [11:32] mgz: there are lots of things there that can easily be got right from the word "go" [11:32] do I have to hit you for that pun? :) [11:32] * rogpeppe was blithely oblivious [11:33] * rogpeppe apologises [11:34] i dunno, maybe it doesn't need a review, but... niemeyer, what thinkest thou? [11:34] rogpeppe: I tend to agree with you [11:35] If it's indeed scratch, it can be moved aside [11:35] rogpeppe, mgz: yeah, I'll feel better once we have a routine CL/review/land process in place, but the code now in trunk will be there for a short while and be reviewed in chunks [11:35] niemeyer: hey can you add me to gophers so i can push to goose trunk? [11:35] Even more if there's no review process in place [11:35] This is a major eye-opener [11:37] niemeyer: absolutely, I agree, so how do we handle the gap between the no-review code and the refactoring of it, which is reviewed as usual in steps [11:37] dimitern: i think we should add code to a blank trunk, in steps [11:37] niemeyer: there is review, it's just we're integrating the two initial stabs dimitern and jam did during UDS [11:37] which were not reviewed, they just got written [11:38] rogpeppe++ [11:38] so, jam had some comments about dimitern's code from then, which wallyworld is refactoring into the common set now [11:38] Although, I'll leave that to you guys.. the important thing is that there's certainty that the code that is in trunk was looked over and is sensible and tested [11:39] so, it's essentially the same as having an unmerged feature branch that some parts of which are now being cherrypicked it, and that cherrypick is being reviewed [11:40] niemeyer: unfortunately you were totally right about your config misgiving last night. a test wasn't working properly, and as a result trunk is now broken in a way that's not easy to fix. am v sorry about this. [11:40] pwd [11:47] rogpeppe: If we can't fix it promptly, we should revert it so other people can continue to use it [11:48] niemeyer: i think reverting it is the best plan (i do have a fix, but it's ugly and bigger than i'd like) [11:48] niemeyer: how would you go about reverting it? apply a reverse patch? [11:49] rogpeppe: Right [11:50] rogpeppe: then in your feature branch, merge trunk after the revert but keep the existing tree state, so it's ready to reland [11:52] mgz: would you do that just by copying the tree out and back in? or is there a clever way to merge without updating the tree? [11:52] Yeah, the obvious "re-apply" doesn't work after the reverse [11:52] wallyworld: That's done [11:52] rogpeppe: basically switch to feature, then bzr merge trunk (or whatever branch layout you're using), then `bzr revert .` [11:53] niemeyer: thanks! [11:53] and commit [11:53] so, you keep the merge marker but reject the trunk changes [11:53] mgz: doh! of course [11:53] mgz: i was thinking that reverting would lose the merge merker [11:53] if there are intermediate things on trunk that need saving, you want to do it in two steps, but there shouldn't be in this case [11:54] mgz: I don't think that works [11:54] Because revert reverts [11:54] Including the merge [11:54] if you pass . it reverts the tree contents, not the merge marker [11:55] mgz: dimitern: my changes should be pushed [11:55] mgz: Ah, I missed the . [11:55] wallyworld: thanks [11:55] me too [11:55] wallyworld: thanks! [11:55] np [11:55] i'll address the refactorings tomorrow [11:56] mgz: that's a very subtle distinction! [11:56] hmm, my irc client says it's dead, but i still saw wallyworld's messages [11:56] right, it's less obvious than the inverse which is `bzr revert --forget-merges` which keeps the tree state but loses the marker [12:01] niemeyer: https://codereview.appspot.com/6845070 [12:02] perhaps i should just submit it - it's entirely automatic [12:06] rogpeppe: Yep, sounds sane [12:07] rogpeppe: I'm wondering about the best plan to get that in now.. it'd be nice to have that branch mostly unchanged when it comes back, so we can more easily get it in [12:07] niemeyer: i agree, but it's not an easy fix [12:08] niemeyer: trying to make a fix made me realise a few issues with my current plan [12:08] rogpeppe: Sure, but it can be done on top of it, rather than *in* it [12:08] niemeyer: i'm not sure. [12:08] rogpeppe: ? [12:08]