[08:19] mornin' all [08:25] hi rogpeppe [08:28] frankban: hiya [09:01] rogpeppe, fwereade: isolation suite stuff proposed in https://github.com/juju/testing/pull/5 [09:02] frankban: looking [09:02] thanks [09:03] frankban: if you're going to have a new package (not a bad thing), perhaps isolation.Suite might be a better name [09:03] frankban: although testing.IsolationSuite would probably work fine too [09:04] rogpeppe: testing.IsolationSuite introduces an import loop [09:04] frankban: what's the loop? [09:05] rogpeppe: logging requires testing, isolation (testing) requires logging [09:05] frankban: logging requires testing? how come? [09:06] rogpeppe: the old LoggingSuite (that we need to preserve for backward compatibility) embeds testing.CleanupSuite [09:07] frankban: that seems spurious to me [09:07] frankban: can't we change all the places that use LoggingSuite to use IsolationSuite instead? [09:11] rogpeppe: we can, but that would require fixing all the LoggingSuite tests using env vars. I guess we want to eventually do it anyway, but the idea is to have an incremental step in the direction of our current goal: separate utils/*, charm etc from juju-core/testing [09:12] frankban: alternatively, just pull LoggingSuite into testing. it's easy to break out later. [09:13] frankban: and it's all pretty trivial stuff [09:14] rogpeppe: I like this more, then we have everything into testing: testing.CleanupSuite, testing.Logging(Only)Suite and testing.IsolationSuite [09:14] frankban: that sounds good to me [09:16] rogpeppe: +1, I'll do that. Please let me know when your review is done, and I'll start moving thos eparts [09:28] frankban, rogpeppe: yeah, that sounds reasonable, it doesn't feel like such an awfully large package -- but I note that it's this sort of thing that causes packages to gradually grow (not wanting to create lots of tiny ones) and makes them hard to split up (because the loops often mean you can't split off *one* package, you have to split off two or three) [09:28] frankban, rogpeppe: but I reiterate that in this case I think it's ok [09:29] fwereade: i'd like to move towards loggingsuite not embedding cleanupsuite, and then we can factor out things. [09:30] fwereade: i agree that it's not great that testing is likely to accumulate a big bag of deps [09:30] rogpeppe, yeah, that is the plan [09:31] rogpeppe, but starting by preserving LoggingSuite is the chosen first step on that path === luca__ is now known as luca [09:39] fwereade, rogpeppe: MP updated, and it also seem juju-core must be changed in only one place to use the new logging suite path [10:13] frankban: i'm not that familiar with github comments - i'm *thinking* that each comment is published the moment I click "Comment on this line", but please let me know if you haven't seen any review comments. [10:15] rogpeppe: yeah github comments are "real time" (and I don't like that since I usually iterate a lot when reviewing) [10:15] frankban: yeah, i agree - i very often go back and change mments [10:16] earlier comments [10:16] rogpeppe: except for juju-core, are we aware of other projects using the LoggingSuite? [10:16] frankban: no, i'm pretty sure that juju-core is the only one (well, some of my stuff might do, but ignore that) [10:18] rogpeppe: just another question about your comments: I know the fixture methods are just methods, I used embedding because it seemed sane to me to rely on the gocheck runner, without simulating its behavior (which I agree is not likely to change, but who knows...) [10:20] frankban: i don't think that calling the method is "simulating behaviour" to any meaningful degree. if gocheck doesn't call the methods, we're stuffed, so unit testing by calling the methods seems fine to me. [10:21] rogpeppe: ok I am convinced, this way I can also separate the two tests there [10:45] morning all [10:49] rogpeppe: re-proposed with the changes [10:49] rick_h_: morning [10:50] frankban: looking [10:50] rick_h_: hiya [10:50] thanks [10:52] frankban: do you know if it's possible to see just the new changes, with the comments shown too? [10:53] frankban: (like codereview allows) [10:53] rogpeppe: I don't think it's possible, there is no history when rebasing. I agree reitveld is much better [10:54] the comments are still there and you can click on them to see the old code that was commented on [10:54] frankban: i mean, it doesn't matter much here, but in more complex changes, it's really useful to be able to see the comments and the changes that were made in response. [10:54] but you don't get just the diff in the new changes [10:54] it's an argument for saving rebase until landing I suppose. [10:54] rick_h_: so it's not actually possible to see what changes have been made since a comment (without downloading the patch directly, i guess) [10:54] ? [10:55] rogpeppe: yea, so if we didn't rebase down until after you got the :+1: then you could view commit by commit [10:55] FWIW, that was something that i would do on almost every review [10:55] rogpeppe: that's unfortunate in github [10:55] it's something we can talk about. [10:56] rogpeppe: yea, I've been trying to find time to investigate running reviewboard in our CI environment to help but time hasn't been overflowing lately. [10:56] rick_h_: that's an idea, assuming the final rebasing does not require reviewers eyes [10:56] frankban: yea, in theory it shouldn't [10:56] rick_h_: could you view that on github itself? or would you need to pull down the (unrebased) patch? [10:56] rogpeppe: reitveld left a lot of sour tastes in people's mouth though much of that blame lies more in LP->reitveld [10:57] rogpeppe: so a partial step would be a policy not to rebase your branch down until just before you submit it for merging [10:57] rick_h_: yeah, the lp->rietveld bridge was a bit awkward [10:57] rogpeppe: that would be in GH itself and would get you much closer to what you want [10:57] frankban: I'll add a friday card and you guys can discuss? [10:58] rick_h_: sure, +1 thanks [10:58] rick_h_: i'd find that useful, i think - for complex changes it can be very hard to see what changes have been made in response to a comment, and whether the correspond with what's wanted [10:58] s/the correspond/they correspond/ [10:59] rogpeppe: understood, it's something we fight with LoC limits and multiple reviews required to land on larger branches [10:59] rogpeppe: so we don't always feel that pain ime [10:59] rick_h_: what are the LoC limits, BTW? [11:00] in the GUI 400 LoC and less you need one review and one QA [11:00] over 400 LoC you need two reviews and one QA minimum...possibly 2 [11:00] over 800 ish LoC you need to break it down or bribe reviewers and beg for forgiveness [11:01] rogpeppe: that is more diff LoC than actual LoC [11:01] LoD (lines of diff) [11:01] rick_h_: that's including context, right? [11:02] rogpeppe: yea [11:02] rick_h_: so a one line change would be ~10 LoD [11:02] it's usually closer to 5ish but yea [11:03] hmm, GH doesn't report the real diff size does it. Looking at https://github.com/juju/juju-gui/pull/348 it just has the +69/-14 [11:03] rick_h_: i get 9 lines, not including the file header [11:03] oh yea, hover it I see [11:03] so https://github.com/juju/juju-gui/pull/348 is an 83 LoC diff technically [11:04] rogpeppe: ok, sounds good then. Not normally checking the size of a one line change. It's under any limits :) Then you just need to figure out if self-review is possible. [11:04] rick_h_: the 83 lines looks like 69+14, not the diff output line count [11:04] rick_h_: i suspect git diff | wc will be considerably larger [11:04] rogpeppe: ah right bah [11:05] rogpeppe: I guess it's just habit these day. We're used to breaking down small enough. You're right that we don't currently have a good number in GH like we did in LP [11:06] * rick_h_ makes a mental note to figure out how to port the old rules to GH [11:06] rick_h_: tbh, i prefer lines without context - it doesn't penalise changes which change quite a few individual lines in a simple way [11:07] FWIW my branch in review has +204 −67 and "git diff master | wc -l" returns 425 [11:09] rogpeppe: the magic calldepth value was pre-existing, I don't have that answer, if you do I'd be happy to add a comment there [11:10] * rogpeppe hates the "publish immediately" thing [11:10] rogpeppe: heh, ok I'll add a todo [11:11] rogpeppe: also, when a review is completed, we usually add a final comment (not inline) so that the author knows when to start looking for comments [11:11] frankban: yea, we used to have different limits based on language back in launchpad. JS could have more than python in that case. [11:12] +1 for the overall comment after all the in-lines are done [11:12] frankban: where do you add that final comment? [11:13] rick_h_: yes, also go diffs can be longer than python ones (gofmt stuff etc) [11:13] frankban: oh, i see, on a different pae [11:13] page [11:13] rogpeppe: yeah, in the conversation tab [11:13] i think there should be an exception for low complexity diffs, particularly mechanically generated changes [11:13] definitely [11:14] for instance, in Go, you may well change an import path which might affect 1000s of lines, but it can still be a trivial change [11:14] it's got to be a judgement call in the end, i think [11:14] yeah [11:16] rogpeppe: how do you merge stuff in github? just use the big green button? [11:16] frankban: i've no idea :-) [11:16] frankban: i am an utter git newbie [11:16] :-) I'll ask on #juju-dev [11:17] yea, just hit the green button [11:17] until we get the libraries in CI and using the :shipit: lander [11:22] rick_h_: cool, merged [11:31] rogpeppe: ok, golxc uses logging.LoggingSuite, I'll update that and then juju-core [11:33] * rick_h_ heads to take the boy to day care [11:33] rogpeppe: if you get a sec can you add a card to the board please for your current work? [11:34] rick_h_: ah yes, will do [11:51] rogpeppe: could you please take a quick look at https://code.launchpad.net/~frankban/golxc/fix-logging-suite/+merge/221210 ? [11:51] frankban: not on codereview? [11:52] rogpeppe: no lbox files in golxc [11:52] frankban: you can still use lbox [11:53] rogpeppe: you are right, let me create that [11:53] lbox propose -for lp:golxc/trunk [11:54] rogpeppe: https://codereview.appspot.com/92660046 [11:55] frankban: i'm not sure about hardcoding /usr/bin there [11:56] frankban: who's to say whether that's the location that the user is using for their lxc binaries? [11:57] frankban: i think that probably commandArgs.SetUpSuite should save the value of $PATH, then TestCreateArgs etc can restore it [11:58] the errors are like this: http://pastebin.ubuntu.com/7536121/ [12:01] rogpeppe: +1 on saving the PATH [12:07] rogpeppe: updated [12:16] frankban, afaics bug 1324097 is still an issue (just filed that) [12:16] <_mup_> Bug #1324097: charm get api doesn't work with store charms [12:17] hazmat: cool will add that to our maintenance backlog to look at [12:17] hazmat: or is that related to the recent refactor work? [12:18] rick_h_, its been a bug in that implementation since it was done [12:18] hazmat: ok cool, added to our on deck maint. [12:26] hazmat: we are now working on breaking the store into a separate project. rick_h_: is the goal to have the store itself expose an API for getting charm files? [12:27] frankban: yes, it'll be part of the api v4 [12:27] frankban, not related [12:28] frankban: speaking of going to share a doc with you to keep an eye on [12:28] frankban, unless your going to remove the broken api method [12:28] frankban: but as hazmat says, this is more a store bug issue and with us working on the store it's something we should keep an eye on and be willing to update as we bring up ownership. [12:29] frankban: and things like this will be great for bringing up new go/store devs [12:29] hazmat: that's what I was asking, we'll take a look at that, thanks [12:29] rick_h_: +1 [12:34] its not really a store api atm, the bug is against the state server api.. [12:34] rick_h_, apiv4 of charmworld? what's the delta on that? i was looking at implementing v3 api against the env to be able to support demos [12:34] hazmat: TBD [12:35] ic [12:35] hazmat: once we pull the store out we'll be working on defining api v4 to fix issues with v3, add current store functions required, and adding new ones for bundles/etc so that they're loaded like charms [12:48] rick_h_, what version of osx were you on? [12:48] re bug 1323803 [12:48] <_mup_> Bug #1323803: ssl handshake fails on osx

[12:49] hazmat: hmm, latest? /me checks [12:49] 10.9.3 [12:49] hazmat: and the openssl version matched the linked url discussion [12:52] rick_h_, so this is an osx and python issue. [12:52] hazmat: yes [12:52] hazmat: and webcocket library issue perhaps [12:53] hazmat: I chased it down enough to get close but filed a bug from there. Was trying to help that stein guy get notes on doing his demo stuff from osx and it's more work than I've got time for before I leave tomorrow [12:53] rick_h_, no.. its deeper than that [12:53] hazmat: I've added it to our board to look into as we'll hit this with our current work to make juju-quickstart work on osx [12:53] hazmat: right, but it sounds like there might be config/ways to enforce ssl3 at handshake? [12:53] and skip ssl2 [12:53] rick_h_, its an libssl issue.. the best fix we can do without modifying python or osx version of ssl [12:54] is to change the server to only do ssl3 or tlsv1 [12:55] hazmat: cool, yea I'm not sure if there's a decent work around for the client or it requires server changes. I figure we can't be the first to hit this stuff (and a google search proves we're not) [12:55] rick_h_, there is no workaround for the client [12:55] without changing python versions, patching py2.7, bundling a new libssl [13:13] * hazmat upgrades his osx machine to 10.9 [13:29] guihelp: I haven't seen this kind of failure in a CI build before and I'm not really sure what went wrong: http://ci.jujugui.org:8080/job/juju-gui/1108/console [13:29] kadams54: looking [13:30] kadams54: so your failure was in IE https://saucelabs.com/jobs/fc4e2430d0da47ae8d17960df1bd795d to go look at the sauce data [13:30] kadams54: and the failure was in the notifier widget, which has a giant "FIX ME" because it causes spurious failures so this means just retry. [13:30] Damn you notifier! [13:30] :) [13:30] kadams54: so get that link you have to find the top of that suite run where the link is output [13:31] Yeah, this is one of the tests that consistently fails inconcistently in local dev [13:31] Ah yes, I see the URL now. Thanks. [13:31] How do I trigger a retry? Delete the "Test FAILed" comment? [13:32] yep, notifier is the one place we still have some timeout based stuff that doesn't clean up well and hits race conditions. To fix it means to really refactor the code heavily so it's a maint. card of work to do [13:32] kadams54: no, you have to actually login to jenkins and "build with parameters" and put the sha in [13:32] * rick_h_ checks of kadams54 has a jenkins account [13:32] heh, guess not [13:40] kadams54: can you please help look at the review backlog and grab one or two please? [13:41] rick_h_: I would if this wasn't my swap day :-) [13:41] kadams54: oh right, wtf get out of here [13:41] I'm just here to try and get my branch landed… [13:41] * rick_h_ boots kadams [13:41] LOL [13:41] Will do. [13:41] yea, don't worry about it. run away. I'll make sure it gets landed today [13:44] jcsackett: class based views [13:45] * jcsackett blinks [13:45] did i miss some chatter? [13:45] :P [13:45] jcsackett: no, but it just popped in my head [13:56] Makyo: hatch halt the line, we need to clear out reviews please before working on anything else. [13:57] Makyo: hatch kadams is out today so really need your help to clear the backlog. I'll help out after my call at the top of the hour [14:02] rick_h_ sure [14:16] rogpeppe: any idea about why the new suite produces tons of errors? https://code.launchpad.net/~gz/juju-core/logging_dep_fixes/+merge/221228 [14:18] frankban: almost certainly because it's calling an external command that relies on some environment variables [14:18] frankban: for example, $HOME will not be set [14:18] rogpeppe: we are using LoggingCleanupSuite, not IsolationSuite [14:18] frankban: ah. hmm. [14:18] frankban: can you reproduce the errors yourself? [14:19] rogpeppe: yes [14:20] frankban: hmm, seems a little odd to me - i'd try rolling back selectively to see where the problem started [14:21] rogpeppe: oh maybe I've found something [14:22] * rick_h_ changes location back to the house. back in a sec [14:22] ccccccdilrkrtfngcdcubbvfldjujftufgbrdufvirfj [14:22] ccccccdilrkrgknbcenkijtgtjflrffcrdlivielkfrr [14:23] bah, yubikey by the headphone jack fail [14:23] * rogpeppe authenticates as rick_h [14:36] bah, was my password so obvious? [14:41] lol [14:59] jujugui call in 2 [15:01] bac: around today? [15:15] y'all sounded amazing on my new noise cancelling earbuds! so lifelike, except for the lack of ambient noise. [15:15] next time I'll whisper at you so it's like i'm IN your head [15:15] bac: <3 those. I got those before my last trip and use them a ton now [15:16] hatch: hah. [15:16] rick_h_: got them mainly for flights. they have to do all instructions in english and spanish and it goes on forever. [15:17] bac: yep, why I got them [15:17] luca how did you make that Las Vegas story on G+? [15:18] hatch: it’s made automatically from the pictures I took on my phone. [15:18] so you just upload them into the same album and it 'just works' ? [15:19] because that's really cool! [15:19] hatch: I’m not sure, I take the pic, it uploads on wifi, I then usually add it to a public album (this one: https://plus.google.com/u/0/photos/113969209489447903536/albums/6006958803479294513) and then it makes it [15:19] hatch: I think it’s triggered off of a series of photos [15:19] cool, must be a new type of auto-awesome [15:20] hatch: so if you take a lot of a certain period of time it knows your somewhere special [15:20] yeah [15:20] maybe it also requires the GPS to be on [15:20] so the photos are geo tagged [15:20] it did one for my holiday in Italy too which is better https://plus.google.com/113969209489447903536/posts/Vr6GLXYdkT6 [15:20] yeah, I think it needs GPS [15:20] My italy holiday story is all based around location [15:22] cool - so were you biking in that race? [15:22] hatch: No, thats the Giro, the second biggest professional race. [15:23] hatch: I followed it for 5 days [15:23] it’s like the tour de france [15:23] ohhh cool, I didn't know people did that :) [15:23] you're like a bike groupie :P [15:23] just the Italian version of it which has more climbs and worse weather [15:23] haha yeah [15:24] Looks like it was a great time [15:24] and this story is really awesome :) [15:24] it was great, a lot of fun, a lot of riding and driving [15:24] I was really tired after it hehe [15:24] the story came out really good [15:25] So how does one follow a bike race? You fly there then bike behind them? [15:25] it’s difficult [15:25] and complex [15:25] I took my bike over [15:25] and a rucksake of cycling clothes and a few casual stuff [15:26] you can’t cycle the routes because they move too fast [15:26] and the roads get cloased off about an hour before they come through [15:26] usually you get up early in the morning, find a good spot of the course to watch them and spend the time waiting by cycling a part of the course [15:27] every night is a different hotel [15:27] then after they pass drive ahead? [15:27] hatch: luca yea it goes back through all your photos and builds a story using time/location info [15:27] yeah, you shoot round to a different part of the course [15:27] every morning you check out of a hotel [15:28] so in 5 days we covered 1000’s of km’s, rode about 250km, slept in 4 different hotels and got up every morning at 6:30 [15:28] heh sounds like an awesome trip :) [15:28] and makes for a great story :) [15:28] hehe [15:28] thanks [15:40] jujugui quick review/qa https://github.com/juju/juju-gui/pull/347 [15:40] I can do it [15:40] #3 for today :P [15:40] I feel a little like a gatekeeper [15:40] today is review day in the UIEng house [15:41] Makyo I THINK your CI failures are the spurious ones [15:41] Oh, it hadn't loaded the comment. Let me check. [15:41] I still had the "This can be automatically merged" [15:42] I'll rerun. [15:48] frankban: what commands have you been using to propose a change to github.com/juju/testing ? [15:48] frankban: are you using the command line or the web UI? [15:48] rogpeppe: web UI [15:48] frankban: ok :-\ [15:52] anyone know how to create a pull request from the command line? [15:53] onnne moreeeee [15:53] frankban: also, what command do you use to do the rebase? i always try to read the help for rebase and get totally flummoxed by the maze of flags and possibilities [15:54] code reviews all caught up and shipping the ones that can be shipped [15:55] rogpeppe: rick_h_ can help you more with rebasing, I hate that. I created a script which helps me collapsing changes into a single commit without rebasing, but I am sure it can be considered exotic. [15:56] rogpeppe: anyway, here it is, I called that git-prepare (so that you can run it with "git prepare"): http://pastebin.ubuntu.com/7537428/ [15:57] frankban: thanks [15:57] frankban: wow [15:58] rogpeppe: oh, it uses git sync: http://pastebin.ubuntu.com/7537446/ [15:59] rogpeppe: it assumes origin is your own remote (e.g. github.com/rogpeppe/testing) and juju is the central remote (github.com/juju/testing) [15:59] frankban: BTW your first sed command could be a little simpler: sed -n 's/^\* //p' [16:00] frankban: ah, i've only got one remote - i've been pushing to github.com/juju [16:00] frankban: is that considered bad form? [16:00] rogpeppe: yeah, it is really just a quick hack to make me at least understand the process, because I really don't get rebasing [16:00] I have to spend some time learning it I guess [16:02] rogpeppe: it seems a more usual workflow is 1) fork the project on github 2) work on a branch of your fork and 3) propose your branch for merging into the original one (usually develop, but in the juju case I saw master is used) [16:03] rogpeppe: to do that, I basically removed github/juju/testing in my $GOPATH, cloned from my remote, then added the juju remote [16:03] frankban: i *think* you should just be able to do git remote add [16:03] rogpeppe: and you can use my "git sync" to sync the two remotes if you like it [16:03] sorry was afk [16:04] rick_h_: just being my usual git-confused self :-) [16:04] rogpeppe: yeah, but I wanted origin to be my fork, not juju, and I haven't looked at how to rename remotes [16:04] rogpeppe: heh, it takes some learning for sure [16:04] git makes a lot of sense once you understand wtf is going on under the hood :D [16:05] rogpeppe: we've got a workflow in the gui hacking doc to help. It has some helpful aliases, process, etc [16:05] https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow [16:05] of which, I use none because I'm a masochist [16:05] hatch: other versioning systems make a lot of sense even before understanding C [16:05] rogpeppe: it tries to work through setting up the two remotes, sync'ing between them, and keeping your branch up to date [16:06] frankban haha, well git is special :P [16:06] Makyo not sure if you noticed - I assigned a card for you under Project 1 [16:06] i just wc'd the combined output of all the git help commands. 21480 lines. [16:06] today is the day I break non-il flag [16:07] that's quite something for something that's just a glorified fs [16:07] rogpeppe lol!! [16:07] rogpeppe actually it's a glorified db [16:07] :) [16:07] rogpeppe: this can help: http://git-man-page-generator.lokaltog.net/ [16:07] ^ hahaha [16:07] :P [16:08] frankban: ha ha. is that markov chained from the git man pages? [16:08] jcastro: sent a nice github link out [16:09] rogpeppe https://www.youtube.com/watch?v=ZDR433b0HJY This video is a great intro to git and actually uses git without any of the git commands to show you how it works [16:10] hatch: i think part of the problem is that everyone these days seems to learn by example, whereas i think i learn best by understanding the primitives [16:10] rogpeppe: sadly that's absolutely realistic, the real git help is stackoverflow IMHO [16:11] rogpeppe then that video is your Yellow Sun [16:11] holy crap I'm a nerd [16:11] hatch: i do actually understand how the *underlying* primitives work (well, mostly) - but the primitives we have to work with are the actual git commands [16:12] hatch: http://en.wikipedia.org/wiki/Yellow_Sun ? [16:12] rogpeppe http://en.wikipedia.org/wiki/Superman [16:12] :D [16:13] superman gets his powers from the yellow sun [16:13] hatch: ah, ok. i'm not big on comic book fiction [16:14] * rogpeppe watches the video [16:14] lemme know what you think [16:14] :) [16:14] hatch, okay, thanks. [16:18] luca Paolo sounds like someone who uses Reddit :P [16:18] hatch: rofl [16:18] haha [16:25] looks good luca [16:25] hatch: does the video cover rebasing, BTW? [16:25] hatch: thanks :) [16:26] rogpeppe it has been a long time since I've seen it so I can't remember. [16:26] hatch: ok [16:26] was there a certain question you had about rebasing though that I might be able to answer? [16:30] * rick_h_ goes for food [16:35] Makyo just FYI you'll need the il flag for your branch [16:35] it doesn't happen with the inspector on the right [16:35] Alright [16:36] hatch: specifically, if i want to rebase my commits before upstream merging, what would be the usual options and arguments that i'd need? [16:38] ok assuming you haven't merged anything into this branch since you branched it from develop(or master or whatever your source is) you will run `git rebase -i HEAD~3` where 3 is the number of commits you want to rebase [16:39] say some new code landed in the source branch that you wanted in yours, ----do not merge that branch in---- run `git rebase develop` where develop is the source branch, this will re play your commits on top of the newly updated branch [16:40] hatch: what if i *did* merge that branch in? or is that a "you're fucked now, boyo" kind of thing? [16:41] well....not totally....but it's considerably more work :) [16:41] think of git commits always wanting to lay layers on top, if you smush some in the middle it's going to break your sandwich [16:41] (at least the way we do it) [16:42] hatch: ok, so in general i should *never* merge trunk when developing a branch? [16:42] hatch: (unlike standard bzr usage, for example) [16:43] correct - if you really need code thats landed use `git rebase trunk` and, assuming this branch was branched from trunk, it will update your branch to the latest code in trunk and re apply your commits on top [16:43] btw not everyone agrees with using rebase - the git world is really of two camps, the rebasers, and the not :) [16:43] hatch: IME, you almost always want code that's landed, because you need to check that your changes work in the context of all the changes that have landed since you started work on the branch [16:44] hatch: i think given the lack of nested commits, rebase is the only reasonable way [16:44] yep, so running `git rebase trunk` will get you that [16:44] assuming your branch was branched from trunk [16:44] git rebase [16:44] hatch: so the source branch argument must be a direct ancestor of the current head? [16:45] hatch: ah, no, i see [16:45] no, but to keep a clean commit history it should be [16:46] cool [16:46] hatch: where's the HEAD~3 syntax documented? [16:46] hmm, not sure, lemme look [16:47] hatch: and why do you want to make it interactive (the -i arg) ? [16:47] say you had 5 commits, and you wanted to keep 2 outside ones but smush the other 3, this will let you pick and choose ( you can even re order the commits ) [16:48] and otherwise it smushes them all down to one, right? [16:49] hatch: one other thing: does rebase actually commit anything, or do you have to rebase, then commit? [16:50] I think you need to use --autosquash to have them automatically smushed [16:51] rogpeppe it rewrites history so it will be committed but not pushed - if you have pushed those old commits to a remote repo you'll now have to do `git push -f` as the histories won't line up [16:51] hatch: ah, so when people say "rebase before proposing", that's what they're implying? [16:52] rogpeppe well some people code with checkpoint commits and you should only commit logical commits into the main repo - so they want you to get rid of the checkpoint commits and turn them into 'topic commits' [16:52] hatch: (--autosquash, that is) [16:52] and when I say rebase rewrites history...it only rewrites the high level history so if you screw up you CAN get stuff back http://stackoverflow.com/questions/134882/undoing-a-git-rebase [16:53] that's why you never want to commit passwords/keys etc into GIT because it's VERY hard to truly delete something [16:54] hatch: ah, i didn't know about the reflog [16:57] if you think of git as an api on top of a database you realize that you can do pretty much anything once you figure out how the commands work :) [16:58] rogpeppe sorry I can't find where the HEAD~3 syntax is documented. But it means from HEAD move two commits back [16:58] HEAD~1 points to head [16:59] weird I know... [16:59] it's like array negative syntax [16:59] [-1] [16:59] is the last char [16:59] [:-3] is the last three chars or commits in this case [16:59] inclusive of HEAD [17:00] hatch: so if i want to do the equivalent of "bzr push", squashing all the commits i've made into one commit message, i look in the log to find out how many commits i've made, count them (call it $n), do "git rebase HEAD~$n", then do "git rebase origin" ? [17:01] hatch: hmm, but i don't see a place to specify the commit message there [17:01] close but not quite [17:01] :) [17:01] hatch: and "git rebase HEAD~$n" isn't going to do anything, is it? [17:01] hatch: hence the -i flag [17:02] `git checkout ` `git pull ` [17:02] hatch: but i hate interactive commands (i almost never use them) so i'd like to know how to do this non-interactively [17:02] `git checkout