[07:17] <LarstiQ> JPeterson: git merge = bzr merge; bzr commit
[08:32] <jml> hey, it's been a long, long time since I submitted something to bzr. How do I land a patch to bzr?
[08:32] <jml> I'm not sure if I've got commit privs,
[08:33] <jml> but poolie gave me the go-ahead for https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850
[08:36] <jml> but when I pqm-submit, I'm told it can't verify my gpg kkey
[08:54] <mgz> jml: the normal way is lp:hydrazine `./feed-pqm bzr`
[08:55] <jml> mgz: ok.
[08:55] <jml> wow, hydrazine, huh?
[08:56] <mgz> and you then 'n' till your proposal, 'm' set the message, and 'e' gpg sign and email for pqm to land
[08:57] <jml> mgz: ok, thanks.
[08:58] <jml> mgz: unfortunately, I have to step away for a bit now, but is it OK if I ping you later if I have trouble landing this?
[08:59] <mgz> jml: certainly
[08:59] <jml> mgz: ta
[08:59] <fullermd> I'll be around to be completely unhelpful too, if that'll help.
[09:01] <jml> fullermd: I was going to say "possibly", but I'm not sure that's strictly true. I appreciate the gesture though.
[09:02] <fullermd> Oh, well, you can just lie to me about it.  I do it to me all the time, and I never seem to catch on.
[10:14] <jml> fullermd: I'm just not sure it's logically possible for being completely unhelpful to ever help.
[10:16] <fullermd> Pfft, logic.  What has logic ever done for me?
[10:22] <jml> mgz: does hydrazine just loop?
[10:22] <jml> mgz: also, it looks like I'm not a committer.
[10:23] <jml> mgz: so maybe I should just ask you to merge https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850
[10:23] <mgz> yes, blast, and okay.
[10:24] <jml> mgz: thanks :)
[10:26] <mgz> ah, and your branch needs to be marked approved, which is why it doesn't appear in the list
[10:26] <mgz> so, pqm may in fact allow you to land it
[10:27] <mgz> want to give it a go? if you get rejected, I'll do it.
[10:30] <jml> mgz: sure, I'll try now.
[10:30] <jml> PQMException: 'Failed to verify signature: gpgv exited with error code 2'
[10:30] <jml> mgz: ^, I think you need to do it.
[10:31] <fullermd> Maybe pqm forgot how to commit to bzr...
[10:31] <mgz> I shall capture a webop later and get you added, landing now.
[11:24] <yaiza> hi!
[11:24] <yaiza> is it possible to rename a branch in launchpad?
[11:25] <yaiza> I would like something like: lp:~ybailen/canonical-openerp/employee-registry-payroll -> lp:~ybailen/canonical-openerp/canonical-payroll
[11:25] <yaiza> keeping the versioning
[11:25] <yaiza> but I'm not sure if this is possible
[11:26] <jpds> yaiza: Yes, click "Change branch details" on the Launchpad page.
[11:26]  * yaiza tries
[11:33] <yaiza> hmm, if I choose Target branch as Personal I get this error "Only private teams may have personal private branches."
[11:46] <yaiza> jpds^ ?
[11:48] <jpds> yaiza: But you only want to change "Name".
[11:49] <yaiza> jpds, if I leave Branch Target as it was: canonical-openerp then I get this error: "Private branches are not allowed for target Canonical OpenERP."
[11:49] <yaiza> so I tried to change that
[11:49] <yaiza> with no success :(
[12:02] <mgz> yaiza: you can ask for help in #launchpad if you're stuck
[12:03] <yaiza> ok mgz, thanks
[12:53] <hno> How do I add --no-trees flag to an existing shared repository? Just noticed I forgot specifying it when creating a shared repository some time ago.
[12:55] <hno> I know how to drop the working trees from it's branches. But like the flag to be recorded so bzr branch remembers to do the "right" think when branching.
[12:56] <fullermd> hno: There's an arg to 'reconfigure' for it.
[12:57] <hno> fullermd, thanks!
[13:06] <hno> To rusty on bzr merges. Need to backport a working branch to an older branch point. Is there an easier way than to cherry pick each revision listed by bzr missing?
[13:07] <fullermd> Mmph.  Well, if your looking at "cherry pick _each_ rev", the answer would just be to do a merge.  But since you're asking, I presume you're wanting to actually skip some...
[13:07] <fullermd> You can do a merge -rX..Y to grab just a range.  It would still be a cherry pick if the graph isn't connected, but it would at least get you N at a time instead of 1.
[13:08] <fullermd> Though that's a drawback too, in that it mushes more things together and gives you more chances for big conflicts.
[13:08] <hno> fullermd, the working branch is based on trunk, and need the same changes based on a release, skipping all the changes between the release and current trunk.
[13:16] <hno> Do "bzr merge -r branch:../trunk..-1 ../trunk-feature-branch"  look sane?
[13:16] <fullermd> Not at all   8-}
[13:17] <hno> Any saner suggestion?
[13:17] <fullermd> It may be _correct_, of course.
[13:17] <fullermd> At a glance it _looks_ like it's asking for what you described, so it may be right.
[13:17] <fullermd> Does twist the eyes a bit though.
[13:19] <hno> "bzr merge -r submit:..-1 ../trunk-feature-branch" is probably better.
[13:23] <hno> "bzr merge -r submit:.. ../trunk-feature-branch" works as well, but not sure it's documented that one do not need to specfy the last revision in the range.
[13:23] <fullermd> It is.
[13:24] <hno> where?
[13:24] <fullermd> No idea   :)
[13:24] <fullermd> But it is an explicit feature, and I know it's in the test suite.
[13:42] <hno> Hm.. that merge for some reason set my submit branch to the trunk-feature-branch. Not what I intendend.
[13:53] <fullermd> merge will always set the submit branch if it isn't already.
[14:07] <hno> and branch don't..
[14:10] <hno> In which use case do merge implicit --remember if unset produce a meaningful result? To me it's only confusing.
[14:19] <LarstiQ> hno: all cases where there is only ever one branch you want to merge from
[14:20] <LarstiQ> hno: like merging trunk into feature branches
[14:20] <LarstiQ> hno: meaningful, but still can be confusing (re: list discussions about this)
[14:23] <hno> LarstiQ, in those cases parent is also trunk and separate submit location is not needed.
[14:26] <LarstiQ> ah hmm, submit
[14:26] <fullermd> Yes, but merge uses a separate saved location.
[14:26] <hno> it uses parent is submit is not set.
[14:26] <fullermd> Right.
[14:28] <LarstiQ> hno: in the cases where it makes sense to submit to the location you merged from then :)
[14:29] <LarstiQ> but it becomes less obviously the right choice I think
[14:31] <hno> there is a --remember flag for the odd cases needing it..
[14:39] <LarstiQ> hno: on the other hand, when do you want submit to be something different without setting it explicitly??
[14:40] <LarstiQ> argh
[14:40] <LarstiQ> s/?//
[14:47] <hno> LarstiQ, exactly. I do not want merge to set the submit branch for me when doing a random merge from some other branch.
[14:47] <hno> when otherwise only using parent.
[14:48] <LarstiQ> right
[14:48] <LarstiQ> does anything using submit fall back to parent if submit is not set?
[14:49] <LarstiQ> that would be rather annoying
[14:49] <hno> LarstiQ, yes.
[14:49] <hno> bzr merge, and also submit: revision spec in general so also bzr diff etc.
[14:58] <LarstiQ> hno: right, so how to balance
[14:58]  * LarstiQ would (now) lean towards not setting it automatically
[14:59] <hno> Yes. Unless there is some very common use case which I fail to see where it makes sense.
[15:25] <fullermd> Available evidence (it's there, and hasn't been a major cause of complaint in the last N years) suggests it does OK in the common case.
[15:25] <fullermd> The whole arena has certainly been the cause of plenty of acrimony in the past.