[00:19] poolie: Guessing based on RHEL4 -> RHEL5, I'd guess that RHEL5 will stay relevant for about a year and a half. [00:20] hi there [00:20] ok [00:21] iow roughly the same timeline, or perhaps a bit later than we may need to support 3.x [00:37] poolie: Yeah, and RHEL6 has 2.6.5. [00:37] poolie: So, I imagine you're still catching up from vacation and all. Will you be able to take a look at the loggerhead work at any point? [00:37] oh, hi [00:39] wow, nine reviews [00:39] mkanat, you should ask jam too, as he's patch pilot this week [00:39] poolie: Okay. [00:42] hi spiv! [00:42] Hi :) [00:44] welcome back [00:46] poolie: The specific review that I'm waiting on is https://code.launchpad.net/~mkanat/loggerhead/raw-prefix/+merge/44682 [00:46] yeah, just reading it [00:47] poolie: Okay. :-) [00:47] to be precise, i'm just asking for a second review from someone who's handled this issue elsewhere [00:47] it looks good to me [00:47] poolie: Okay. [00:47] poolie: I've also handle this issue elsewhere, FWIW. [00:47] *handled [00:48] poolie: How does authentication work for loggerhead for private branches on launchpad, do you know? [00:48] poolie: The LP version of this may need some special magic. [00:49] i know you're familiar with it [00:49] s/it/xss elsewhere [00:49] i don't know much about how it works in detail [00:50] Not just XSS, but almost this specific issue, of serving untrusted content. [00:50] we had a big internal thread about xss in general, so i just thought i'd let those people comment if they want to [00:50] Okay. :-) [00:50] you're right it may need to be updated if this is deployed [01:04] mkanat, i replied [01:05] can i help with anything else? [01:07] poolie: Awesome, thanks. That should be it for now. [01:57] mkanat: private branches have oauth triggered [01:57] lifeless: All right. And how is that persisted? [01:57] mkanat: well, not oauth, but auth in general [01:57] lifeless: Like HTTP Auth? [01:57] mkanat: cookies. It seems to be pretty bustified just now. [01:57] lifeless: Okay. [01:57] We'll have to do something special for that, then. [01:58] I'd just use the timelimitedtoken table [01:58] its meant to be pretty generic [01:58] Is that in LP? [01:58] yes [01:59] Okay. Yeah, that's what I'd use. I don't think codebrowse has access to that, though, no? Or I'd just get one via the API? [01:59] the way it works is this: [01:59] - we advertise a url on the appservers [01:59] - requests to said url: [01:59] - add a token [02:00] lifeless, do you mean you give a positive or a negative value to the manual "feed to pqm" step? [02:00] - generate a redirect to the content-domain with the token as a query parameter [02:00] poolie: manually feeding allows user control and approval-before-landing. [02:01] because you can say status=approved, comment='approved conditional on fixing X'? [02:01] mkanat: the 'content-domain' is a wild-card domain so that no user supplied content can attack each other or lp cookies. [02:01] poolie: yes [02:01] is that any better than saying status=needreview, vote=approved, comment='ok to land when you do x'? [02:01] poolie: yes, in several ways [02:02] poolie: firstly the approver is the reviewer not the lander; secondly the mp gets out of the to-review queue. [02:02] lifeless: But loggerhead is not a part of launchpad, so I'm not quite sure what you're advising me to do. [02:02] mkanat: the one deployed at bazaar.launchpad.net is [02:02] mkanat: its an appserver in the general sense [02:03] lifeless: Okay. [02:03] lifeless: And so it can use the LP APIs and so forth and generate a token? [02:03] we may need more api glue etc to let loggerhead issue a token, but thats doable. [02:04] lifeless: Okay. I've already got the domain system in place in loggerhead itself. [02:04] lifeless: I just need to check and validate a token for private branches. [02:04] mkanat: so each branch gets its own domain ? [02:05] lifeless: Yeah. [02:05] kk [02:07] so, getting it out of the queue, if you want, is equally well accomplished by setting it to wip [02:07] i don't see how the identity of the approver makes the process less blocking [02:08] you asked how it was better [02:09] is this better? [02:09] on the one hand you have [02:09] A says "I'm marking the approved (but not really approved)" [02:09] thats not what I'm saying [02:09] and in the other case, B says "I'm marking this approved because A said it was ok when I did X and I've now done it" [02:10] I'm saying 'approved but consider X or Y' [02:10] which is approved [02:10] but maybe not time to land it [02:10] ah, so not conditionally approved, but [02:10] approved, with comments [02:10] lifeless: Where in the API would I look to generate myself a token? [02:10] mkanat: tokens aren't exposed in the API yet [02:10] mkanat: this is the glue needed that I mentioned [02:10] lifeless: Ahh, okay. [02:11] would you care to file a bug requesting the ability to hand out tokens ? [02:12] poolie: marking as vote: approve, status: WIP also tends to hide a branch, whereas currently +activereviews gives a fairly good indication of branches that are close to landing. [02:12] lifeless: Sure. [02:12] mkanat: thanks! [02:12] spiv, true, but... [02:12] I think that's more an issue with Launchpad than PQM vs. Tarmac though. [02:13] i think the ui is just lacking a bucket for "needs piloting, not review per se" [02:13] right [02:13] I think it would be nice for a reviewer to be able to land something trivially [02:14] I don't like the idea of being unable to clearly say 'this is ok now' without causing it to land. [02:14] agree on both points [02:14] landing, like deploying, is something I think human action on adds value [02:14] and vote=approve, status=unchanged doesn't quite feel like it captures the second [02:15] lifeless: https://bugs.launchpad.net/launchpad/+bug/697485 [02:15] it's close, but there's a distinction between "my opinion is this is ok" and "i'm concluding the discussion: this is ok" [02:15] istm the real fix for that is either adding a 'queued' state, or a 'merge' button [02:15] and/or perhaps revisiting the relation between votes and states [02:16] the queued state has been ripped out [02:16] a new implementation is ticking along slowly AIUI [02:16] right [02:16] i think going to tarmac is a step towards this? [02:16] for example, it would make it more rewarding for me, or spiv, or whoever, to add a queue db and ui to launchpad [02:17] I think putting the new implementation in is a step torwards having tarmac [02:17] anyhow, I was simply expressing an opinion [02:17] I doubt I'll be landing anything in bzr in the short term [02:18] i'm glad you read it [02:18] and i appreciate your opinion [02:19] Is it easy to teach tarmac to look for a comment saying "tarmac: ok" or something, not just checking the status? That might work around the conflation of status==approved and "robot should merge it" that lifeless is talking about. [02:19] there are plugins to do that AIUI [02:20] that sort of thing anyhow === Ursinha-afk is now known as Ursinha [02:28] mkanat: I've triaged it to high [02:28] lifeless: Awesome, thank you. [02:29] mkanat: in the new work structure we'll have two teams working on high bugs, it will get got to within a year :( [02:29] lifeless: Hahaha, wow, okay. [02:29] we have a massive backlog we're trying to sort out [02:29] poolie: That will limit the rollout of /raw/ on LP ^^^^^^^^^^^^^^ [02:29] there are a few options [02:30] I could just deny access to /raw/ on private branches until it's ready. [02:30] if there are stakeholder requests for this, we can make it semi-first-among-equals [02:30] mkanat could do the patch to lp [02:30] we can let the teams know its there and see if anyone cherry picks it as an interesting thing within the high bucket. [02:30] lifeless: I'd be happy to write the patch, but that would revolve around contracting emails. [02:30] *details [02:30] (Not emails.) [02:33] yeah [02:33] I realise that [02:33] what I've done is all I can sensibly within our current constraints [02:33] lifeless: Yeah, I know. :-) I appreciate it. :-) [02:43] btw, has anyone in position to fix it noticed the saily PPA build failures with bzr-svn? [02:43] *daily [03:16] mkanat, i guess if you just merge all your stuff to one branch suitable for use on lp that would be good for now [05:25] poolie: Okay. [08:12] hi all ! [08:23] * fullermd waves at vila. [08:23] _o/ [08:25] Seems like a year has passed since last I saw you around ;p [08:27] hi vila [08:27] i'm going now though [08:28] poolie: take care ! [08:28] fullermd: same here, on the other hand, that's one less before we can just relax and enjoy the show :D [08:29] . o O (Nothing beats black humor to start the day... ) [08:29] Wait. There's going to be a time when we can relax? [08:29] hmm, I hope "black humor" has the same meaning in English than in French... [08:29] Oh yes we can ! Bugs can't affect ghosts :) [08:30] I'm saddened at your lack of imagination :( [08:30] I KNOW my clients would never let a little thing like my death stop them from hounding me. [08:31] Or their death, for that matter. I took out a good half dozen before I realized how futile it was... [08:32] nah, you got it all wrong, ghosts CAN trigger bugs, it only works one way... Think about the potential for fun.. [08:32] Oh, I know; we already have a bunch of those files I think :p [08:34] And filed, too. [08:35] see ? [08:35] :D [08:36] Now think about looking at those poor souls running in circles searching for a way to reproduce these oh-so-funny bugs :) [08:36] decades of fun ! [08:36] not mentioning leaks (of all kinds :) [08:37] But you can't even let anybody know. Launchpad logins don't work from the afterlife. You'll have to file a bug about tha.... crud. [08:39] really ? I thought 'ether' in ethernet was afterlife related... [08:40] Otherwise, I'm sure that with all these new wireless protocols... [08:41] I think it means that trying to debug problems in ethernet makes you drowsy. [08:43] right, this just means the latency increases, shouldn't be too hard to address [08:44] Heaven has too many dropped packets, and hell has hellacious latency. [08:50] tsk, heaven, you're sooo optimisitic... [08:52] What, with this angelic face? Where else would I end up? [08:52] ;) [08:53] Alrighty, I just blew an hour sorting video clips. Must be time for bed. [08:54] bed ? [08:56] Yeah, it's this thing that's sorta like sitting in front of the computer, except with less fans and more horizontality. [09:21] sleep is a poor substitute for caffeine. [10:54] Hi ! How can I resolve this: Conflict adding file foo.OTHER. Moved existing file to foo.OTHER.moved. [10:54] I just want current version of foo to be commited. [10:56] bzr resolve foo gives: foo is not conflicted [10:57] argh [10:57] bzr rm foo.OTHER.moved [10:57] bzr resolve foo.OTHER.moved [10:57] but having .OTHER files hanging around sounds broken to me [10:57] sounds like someone accidentally added some conflict files [11:09] matkor: quicksilver is right, you were already in trouble with foo.OTHER already present (that's the one in conflict now by the way, not foo, foo *was* in conflict somehow in the past) [11:11] quicksilver, vila. Ah great thanks. === oubiwann is now known as oubiwann_ === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann === frakturfreak_ is now known as frakturfreak [14:21] heya [14:21] * bialix looking for jam [14:21] who can help me with lp:bzr-merge-into plugin? [14:21] it refuses to work for me [14:27] Isn't that the one which was never updated to work with 2a? [14:29] I'm using pre-2a formats [14:29] but maybe it does not work with new bzr [14:29] maxb: thanks [14:31] it's not big deal to do everything manually [14:56] g'day === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch [16:31] one thing that annoys me about bzr is that when you look at a merge commit, it shows a bunch of modifications as if you did them, instead of them coming in because of the merge. Is there a way to fix that? [16:36] It's not clear what you mean. To me, the fact that the commit is a merge commit fully explains that the changes it introduced involved a merge [16:43] It documents who did the merge, and no information about the constituant changes is lost. I see no problem. [16:43] psusi: Yeah, I can't see what you mean by that either. It definitely does not look like "you did them"; there are fields in the metadata for each revision describing the author and committer, and you can look to see who did the changes. === Ursinha is now known as Ursinha-lunch === deryck[lunch] is now known as deryck [17:04] glyph: see http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45 [17:04] it shows files added, removed, and modified [17:04] but I didn't touch them [17:05] the only file I touched was debian/changelog [17:08] psusi: But, you performed a merge which caused all those files to be modified in that branch [17:08] sure, but I did not modify them in that commit [17:09] That's a very fine semantic difference, which starts to break down as soon as any amount of intra-file merging occurs [17:10] git understands the difference and the diff only shows parts you had to modify to complete the merge... the fact that the upstream branch modified a bunch of files is covered by the commits in the upstream branch history, not by the merge commit [17:11] How do you ask git for such a diff? [17:11] git log -p or --stat [17:13] only any parts YOU actually changed are shown... changes pulled in by the merge are not... which makes sense since they are already documented in other commits [17:14] There's something to be said for that [17:14] my understanding is that git immediately commits the merge, conflict markers and all [17:14] and then you effectively have to merge again once you've sorted out the mess [17:14] no... you commit once you have sorted out any conflicts [17:14] My boss is thinking of switching us from svn to git, but I think git looks overly-complex (no experience with it yet). I like bzr; would git be a pain and is bzr a lot less hassle? [17:14] jamey_uk: _I_ think so :) [17:15] but if there were no conflicts, then the log shows no files modified, and the diff is empty [17:15] jamey_uk: #git might have a different idea [17:15] yeah, going to have to ask in there in a second :) [17:15] psusi: sounds like an interesting feature. bzr could probably have a logging mode where it did that by examining diffs. [17:16] jamey_uk: bzr seems to aim more at being user friendly/easier to understand... I've been using both lately and for the most part, find them equivalent... but there's a few things, like this issue, that I prefer about git [17:18] why is it better that it commits immediately in this case? [17:18] the other day I was very thrilled with git because I found a commit in linus's kernel tree and was describing to an ubuntu developer that it obsoletes a patch they had been carrying. Within seconds I was able to point him to the commit so he could review it, and ask git to verify what upstream release it made it into, and that it was present in the Ubuntu tree [17:19] jamey_uk: it doesn't... what I like better about merges in git is that it doesn't make all of the ( possibly hundreds ) of changes you are merging appear to be one massive patch applied by the merge [17:20] well, merging is a new concept for me to be honest... so this is going slightly above my head [17:21] so when you do a large merge with bzr it does it all as one patch, and git does lots of small patches? [17:22] no. [17:22] what psusi is on about sounds like a ui nitpick to me, unless what glyph said is right (which it may be) [17:23] merging in any dvcs is a way of preserving the individual changes in another branch without flattening them into one big patch [17:26] I'm trying to join #git to get opinion from the other side but FreeNode is telling me: "#git :Cannot join channel (+r) - you need to be identified with services". Yet I registered recently and I am identified :/ [17:32] jamey_uk: any luck yet? try #freenode if not. [17:33] mgz, yeah no luck, going to ask in #freenode now, thanks [17:33] psusi: I don't suppose you know *how* git calculates what to display in that case? I'm having trouble thinking of any way it can separate the two concepts without an intermediate commit. [17:33] well, I guess that's at least one thing bzr has going for it. "Can join IRC channel" [17:34] :D [17:43] jamey_uk: quite a few people actually use bzr clients against svn servers at their work, so there's a fair bit on experience on the mailing list about that. [17:43] it's a way to get your feet wet without doing a big switch. [17:44] but starting with a new little project is probably better for actually learning stuff like developing in feature branches and more distributed workflows. [17:48] yeah I'm thinking of converting our repo to bzr, playing around with making a new feature and such. Although, #git just pointed me to http://whygitisbetterthanx.com/ and the 'cheap local branching' does look good, I'm trying to thoroughly understand the difference. Seems to me just to be bzr branches into a new directory, which is a clone of the original branch, whereas git keeps it as one directory. Is this correct? [17:48] bzr-svn is pretty amazing, but can get awfully slow if used against one-repository-for-the-entire-company's-code svn repositories. [17:49] Also, bzr-svn's representation of files being moved or renamed in svn is rather suboptimal [17:49] By which I mean if you try to merge such changes, it's pain and mess [17:49] why would one use bzr-svn? to get used to bzr's commands whilst still using the same svn repos? [17:51] To get some of the benefits of bzr before the entire team will switch [17:51] Also to actually do a conversion [17:51] ah right [17:51] jamey_uk: bzr can do cheap local branching too [17:51] The thing about git's "Cheap local branching" is that git makes it particularly easy to manage multiple branches within a single repository and working tree [17:52] ah really? I was just told it's a lot more painful when doing lots of branching [17:52] bzr can do much the same, but it's not quite as elegant [17:52] jamey_uk: it's just that bzr starts with a default model which is easy to understand and lets you optimize it once you understand what's going on, whereas git starts with a model that's a mess and hard to understand but super fast [17:52] ah, akin to *nix versus osx [17:52] in a sense [17:52] jamey_uk: 'bzr init-repo --no-trees .' [17:52] then bzr will put all of the revisions into a bucket in '.' [17:53] "Cheap local branching" workflows are possible with bzr, either by setting up a bzr repository, branches, and checkout manually, or by using the bzr-colo plugin for helpful UI additions [17:53] and you can make hundreds of little branches, which are all directories, without copying the whole history [17:54] ahh, when I fired up bzr-explorer the main thing I didn't understand was when I was creating a new repo, I couldn't get my head around what the different types of repo actually meant [17:54] I still prefer the shared repo approach, which performs well and is hard to screw up with, it's only when you get something the size of the kernel you can't use that any more. [17:54] I guess I just don't fully understand the concepts for bzr repos [17:54] actually having a seperate dir for each branch means it's clear what a branch is and where you're working. [17:55] yeah I quite like that aspect [17:55] mgz: why doesn't that work? [17:55] if I convince my boss for us to try-and-then-switch to bzr, do you think there'll be things he'd complain about that git does better? [17:55] mgz: with somethign the size of the kernel, I mean [17:55] One day, bzr will have true git-like branching. It's been hypothesized for a long time [17:56] some context: small web dev team, main repo has ~5000 commit history, 3 people working and frequently need to branch the code but currently don't bother (too much of a headache) [17:56] jamey_uk: The one thing that git has that bzr can't touch is speed. git is blazingly fast. bzr is "usually fast enough" [17:57] Of course, git is also heinously confusing unless you study its philosophy, whereas bzr is quite friendly :-) [17:57] ah, that might be what sways my boss. what about web-based tools for browsing bzr vs git repos? it's not that important, but something we're interested in having [17:57] glyph: mostly because having more than one working tree blows the cache, though also people like not having to do full recompiles when switching branches in the same dir. [17:57] That's the main trade-off as I see it [17:58] yeah, it's the 'heinously confusing' aspect of git that makes me want to shove it away with at ten-foot pole and run into the loving arms of bzr [17:58] glyph: there's precisely one project I have on my dir where any of that actually applies, but people make choices based on what the big boys do. [17:59] jamey_uk: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes <-- this is the Bazaar web viewer. It's called Loggerhead [18:00] for something the size jamey is talking about, none of this really matters, git or a single on-disk tree wouldn't be a useful speed increase. [18:01] so I wouldn't really notice a difference in speed between the two doing regular commit, push, pull stuff? the repo's probably less than a few hundred meg [18:02] I reckon you could notice the difference, but it wouldn't be sufficiently great to cause concern [18:03] what are the equivalents to gitorious for bzr? [18:03] uh, remind me what gitorious is? [18:03] :-) [18:03] having some big binary things versioned might make a difference on spinning rust, having to create megabytes of jpegs can take a little time. [18:03] it looks like a nice hosting/backup solution for git repos [18:04] mgz, spinning rust? [18:04] disk, sorry. [18:05] heh [18:05] generally, you can just push a bzr repo to your server, and use whatever normal file backup mechanism you have. [18:06] I would have to say that Bazaar lacks anything similar to Gitorious [18:06] These questions are ones I'm confronting trying to introduce Bazaar at my organization too [18:06] if you want third party hosted things, there are some options but fancy bzr access (or fancy git access) for commercial will generally mean paying someone. [18:07] I specifically don't want a hosted solution. [18:07] launchpad provides a similar offer to git hosting sites. [18:07] Unfortunately it fails to provide a self-deployable offering [18:08] can you download the github infra? [18:08] jamey_uk: spinning rust is magnetic, rotating media (ie. HD), with all their poor access time characteristics, as opposed to SSD and other truly random access solutions [18:08] To be an ideal solution for me, Bazaar really needs what would essentially be the Launchpad Code feature extracted into a standalone deployable [18:09] yeah, that would be very useful [18:09] thanks very much for your help, I'm still undecided so might just try out both [18:09] is that mostly the web front end? [18:09] or does it include other things maxb? [18:09] psusi: try bzr log -n0 to see sub-commits in bzr merges [18:10] matherick, I don't know an easy way to see what changed during the merge itself, unless it happened to be from the last rev anyway [18:11] mgz: Key other things are the ability to rename and delete branches, manage branch statuses, etc. [18:11] then diff -r 6.1.1..7 works [18:12] mgz: good question, doesn't comparing the merge revision with the last revision merged in do what you want? [18:13] not if it's from a few revisions back, because the common parent isn't the rev you care about [18:13] I don't get what you mean/ [18:13] I think maxb actually has a better grasp on this than I do, but basically... [18:14] if what's from a few revs back? [18:15] also, what psusi says makes sense, and it'd probably be possible to introduce a new revision specifier, something like mergerev:1234, to ask for that [18:15] the same command would be diff -r3.24.1..19 or whatever, which would give you the difference between rev 3 and rev 19, where you actually want the (unrelated to merge branch) 18 as one parent. [18:15] although the exact UI implications need to be thought out [18:15] I agree some ui to do this would be useful. [18:16] mgz: I still don't think I understand what you mean about rev 18 [18:16] why'd you want r18 if it's unrelated? [18:17] well, what changed between rev 3 (which the feature branch is from) and rev 19 includes all the changes from 4..18 - which you don't want in your diff right? [18:17] mgz: but that's not what psusi wanted. He was asking (AIUI) to be able to see what conflict resolution changes he made in order to be able to merge fully [18:18] so we have three parents. 3, common to both, 3.24.1 from the feature branch, and 18, from trunk. [18:18] which should be bzr diff -r 123.., assuming 123 is the merge rev [18:20] well, that's backwards, but yes... *only* if the feature branch originated at r 122 [18:20] otherwise you get all the other changes since then, because those are also differences between the branches. [18:20] no, I don't think you get what I mean [18:20] I have a branch here [18:20] try it and see. [18:20] revno: 15 [merge] [18:21] which merges in revno: 12.1.1 [18:21] bzr diff -r 15..12.1.1 gives me a diff of what I did to resolve conflicts [18:21] actually, it should be the opposite order [18:21] but you get what I mean [18:23] does that branch have non-reverted changes at 13 and 14? [18:23] yes [18:23] hmm === Ursinha-lunch is now known as Ursinha [18:23] because if I do `bzr diff -r93.2.1..103 lp:testtools` that includes the trunk changes since branching. [18:23] I see, it lists the changes from 13 and 14 too, you're right [18:24] that's indeed a problem [18:25] what's really needed is -n for diff, the way it already works for log [18:26] psusi: that deserves to be put in a bug on launchpad [18:34] btw, for all the people discussing git-vs-bzr, there's https://launchpad.net/bzr-colo [18:34] which is basically in-place branches git-style, just built on top of today's bzr [18:35] which I'd claim it git's usability with bzr's speed, but... that's not entirely fair. [18:35] mgz: yeah, that's kinda how I feel about it :) [18:35] git's hard to use in lots of other ways too, apart from its branch layout. [18:35] Srsly. [18:36] colocated branches do have one nice usability feature which bzr lacks though [18:36] and bzr doesn't need plugins to be slow! [18:36] which is a way to synchronize a big pile of unrelated development all at once [18:36] howso? [18:36] yeah, there are certainly circumstances where you plain just need them. [18:37] but once _you actually understand the concept and benefits of colocated branches_, bzr-colo works just fine [18:37] people with super-fancy editors also seem to require one working tree for all branches as well. [18:37] I'd argue that bzr's approach is about 100x easier for people to grasp at the beginning [18:38] mgz: you mean like eclipse? Why? Because it gets confused about "workspaces" and "projects" or something? [18:38] but wouldn't replacing files behinds its back confuse it even more? [18:38] I think it had problems yeah, there were threads on the list about it at any rate. [18:39] the eclipse / MSVC way of writing code is annoying as hell [18:39] because you can't just have files, you need projects and what not [18:40] and it's supremely useless for browsing code you're not working on [18:40] anyway, bzr-colo gives you in-place branches and works well [18:41] which is something to keep in mind next time git people come in asking === beuno-lunch is now known as beuno [18:49] mgz: actually, jamey pretty much nailed it... bzr does squash all of the merged commits into one big patch [18:49] it tells you that they came from another merge, but the diff makes it look like one big patch [18:50] psusi: no, that's not actually what it *does*, but it may well be how it gets presented to you [18:50] mgz: right [18:51] anyway, as mathrick suggested: [18:52] including examples of what the git command does vs. where you had the problem with bzr would be helpful I'm sure [18:53] eg, you linked a loggerhead page, so it could probably also be targetted to loggerhead as well. [18:53] maxb: no, I don't know how git does it, but I would imagine it does the auto merge and then the diff is taken against that... at least that is what the output looks like [18:54] hrm... ok [18:54] psusi: in which case... bzr squashes no more than git does. git just has a pretty rendering mode [18:55] I suppose [19:00] psusi: you don't need to give technical details of what git does [19:01] just explain what it gives _you_ as the user [19:01] thinking how best to do it is something for later [19:03] * mathrick wishes people would learn to give good bug reports, which specifically does NOT include guessing what the receiver might want to hear or do. Just give the relevant information and describe the problem / shortcoming accurately as it affects you [19:03] aye [19:05] https://bugs.launchpad.net/bzr/+bug/697810 [19:07] psusi: good, could you also add a comment with an example output of git vs. what bzr says in the same situation? That will make it slightly clearer what you mean [19:36] mathrick: ok [19:46] mathrick: how's that? [19:49] psusi: the best way of presenting command output is to paste it verbatim instead of paraphrasing, but yeah, that's good enough [19:50] now there's a record in the bug tracker, someone has a chance of looking at it properly [19:51] though, hmm, actually bzr log -p seems to do exactly what you want I think [19:52] in the example I listed, log -p shows +bar in b... if you add --include-merges, it is shown in both r2 and r1.1.1 [19:56] because of this, reviewing the merge commit for non trivial marges is impossible since the diff is the sum of all changes on the other branch, plus any local changes you had to make during the merge, if any. [19:58] this might be a more concrete example. say you have a variable that is used in several places, and on another branch, they add another reference to that variable. In the mean time, you rename the variable. When you do the merge, it will add the new refernece to the old variable name, which you will then need to rename to the new name to get the code to compile. [19:58] with git the diff for your merge will only show the one line change where you rename the reference added in the other branch [19:58] with bzr, you see ALL changes done on the remote branch [19:59] I know, I was just trying to see if log -p didn't do that already, since it seems to for _some_ situations, but not all, oddly [19:59] hrm... where is a situation where it does do that? [20:00] psusi: my local branch here which has a rather simple conflict-resolving merge [20:01] I wonder what the difference is between that and http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45, which was a simple merge with the only conflict being debian/changelog [20:02] it's rather odd, I get exactly what I'd expect to in that conflict-resolving merge, but in a simple merge with _no_ changes, I get a bunch of junk from the merged revisions output [20:02] *no conflicts [20:03] hrm... === luks_ is now known as luks [22:11] Should the lp: alias work out of the box with bzrlib.branch.Branch.open() ? [22:11] in other words: how do I get Branch for lp:foo ? [22:23] enable plugins? [22:24] bzrlib.plugin.load_plugins() [22:24] oh [22:24] let me see [22:24] do I need bzrlib.initialize() around this? [22:24] nope. [22:24]