[07:59] <mgz> morning!
[08:22] <jelmer> hey mgz
[09:02] <mgz> bug 1025030
[09:02] <mgz> looks like something in 2.6 borked loom?
[09:07] <jelmer> mgz: https://code.launchpad.net/~jelmer/bzr-loom/branch5-move/+merge/115302
[09:12] <mgz> jelmer: approved and etc
[10:35] <AfC> I pushed a bzr branch to github, and saw my beautifully tracked renames get turned into removes and adds. Kittens are crying this night.
[10:36] <LeoNerd> YYyyup
[10:37] <LeoNerd> The Linux kernel source code rarely has to rename files, so Linus didn't consider renames a core feature in git
[10:37] <LeoNerd> That's a sensible enough choice given that use-case. It just annoys me when people try to reuse git for all sorts of other things that do want to track renames
[10:39] <AfC> The weird thing is that GitHub actually displays it as a "rename"
[10:39] <AfC> anyway.
[10:39] <jelmer> AfC: git infers renames at run-time, it doesn't store them
[10:39] <AfC> jelmer: yeah
[10:39] <AfC> [I know]
[10:39] <AfC> like I said, think of the poor kittens
[10:40] <AfC> jelmer: if I've gone and used dpush (which rebases, I now see), should I take the now git-v1: revisions as the "real" ones and accept that as a universal replacement for my existing branches?
[10:43] <AfC> jelmer: [I didn't quite realize that sharing my code that way would imply having to rebase all my branches. I understand why it would be necessary, of course. Not sure what workflow makes sense, though]
[10:43] <jelmer> AfC: I wouldn't do this with any existing branches, it will horribly break your existing users
[10:45] <AfC> jelmer: ok
[10:45] <AfC> jelmer: [just me at this point on this particular repo]
[10:45] <AfC> jelmer: but no, I wouldn't want to do it for a major project! :(
[10:46] <jelmer> AfC: you should be able to get back to the old tip by using 'bzr heads --dead-only'
[10:46] <AfC> jelmer: no, it's cool, I have lots of versions of this branch around
[10:46] <AfC> jelmer: I'm experimenting
[10:47] <jelmer> AfC: ah, great
[10:47] <AfC> but if I'm going to offer to share with people via github, that really locks me in to the rebase (and accepting their / those? revisions as authoritative
[10:47] <AfC> is that correct?
[10:47] <jelmer> AfC: yes
[10:47] <AfC> ok
[10:47] <jelmer> dpush is a useful tool, but mostly if you occasionally contribute a fix to a git-based project
[10:47]  * AfC hms, afraid of the implications he hasn't seen yet
[10:48] <jelmer> it's not really useful for working in bzr yourself and allowing others to work in git; for that, you really want roundtripping to work
[10:48] <AfC> jelmer: I remember years ago we talked of being able to preserve metadata when pushing to [Subversion] it then was
[10:49] <AfC> jelmer: round tripping ... as in keeping git and bzr locally, shuttling patches locally, and using git to shuttle from local to remote?
[10:49] <AfC> or as in "use fast-export"
[10:49] <jelmer> AfC: fast-export doesn't roundtrip
[10:49] <AfC> oh
[10:49] <jelmer> AfC: it discards revision-ids, renames, revision properties, etc
[10:49] <AfC> oh
[10:50]  * AfC has been blissfully isolated in bzr only land for the last 5 years, but I'm trying to be more ... accomodating.
[10:50] <AfC> so {shrug} learning curve
[10:54] <AfC> jelmer: [am I missing something? Do we *have* round trip capability?]
[10:55] <jelmer> AfC: no, there is no roundtrip capability
[10:57] <jelmer> AfC: enabling git users to contribute to a codebase in bzr doesn't work particularly well at the moment
[10:57] <jelmer> AfC: the other way around works better; and git-bzr presumably also works reasonably well for git users who want to contribute to bzr
[11:04] <AfC> jelmer: well the goal here is nothing original; would potentially like to host in github; no preference on my part [I host my own branches] but this particular community is github centric and I might be nice to make it easier for them.
[11:05] <AfC> I could just keep using bzr [and self-hosted branches] only, but...
[11:09] <jelmer> AfC: personally, if the community was github centric I would use git for this
[11:10] <jelmer> AfC: it would be nice if things interoperated better, but unfortunately that's not the case at the moment
[13:31] <AfC> jelmer: hey, it's awesome what we have now. bzr-git is fantastic.
[14:16] <trkv> jelmer: hi, I've tried to implement thing we've spoken about last night. Could you give it a quick look and check if I've caught the idea how it's should be done? https://code.launchpad.net/~torkvemada/bzr/commit_hooks/+merge/115348
[15:20] <dash> I'm getting "Tree transform is malformed" errors from 'bzr shelve'.
[15:20] <dash> looks like this: http://dpaste.com/771792/
[15:20] <dash> is this a known bug? anything i should do to work around it? :)
[15:20] <mgrandi> missing parent?
[15:20] <mgrandi> are you..missing the parent? =P
[15:21] <dash> good question. how would I check? :)
[15:21] <mgrandi> is the branch stacked or part of a shared repo?
[15:22] <dash> nope, it's standalone
[15:23] <dash> deryck: hmm wow, another bzr in birmingham? :)
[15:23] <deryck> dash, near Auburn actually :)
[15:24] <mgrandi> im not that familiar with teh bzr internals so im only guessing
[15:24] <mgz> ga, why did people in the US have to be so unimaginative with place naming
[15:24] <dash> deryck: hah ok :) i haven't been down there since shortly after I graduated...
[15:24] <dash> mgz: americans came from england and brought their place names with them!
[15:25] <dash> mgz: also Birmingham was founded as a steel town. so naming after an English steel town made sense. :)
[15:25] <deryck> mgz, it's also not as if dash or I did the naming ;)
[15:25] <mgz> dash: the likely cause is you're shelving the rename/deletion of a directory with an ignored file in it
[15:25] <dash> mgz: hah! ok
[15:25] <mgz> or something similarly finikity
[15:25] <dash> mgz: I am most likely doing that.
[15:25] <mgz> you should be able to just not do that.
[15:27] <dash> yep
[15:29] <mgz> dash: feel free to +affectsmetoo on bug 611739 if that was the issue
[16:10] <dash> mgz: ah, thanks.
[16:46] <lduros> is there a gratis place like github for Bazaar projects?
[16:46] <mgrandi> launchpad, or github using bzr-git
[20:16] <nessita> hello everyone! I was wondering if anyone would have a hint about how to "fix" a branch that is crashing on bzr st. Full traceback is: https://pastebin.canonical.com/70279/
[20:16] <nessita> I'm running bzr   Installed: 2.5.1-0ubuntu2
[20:18] <mgrandi> i dont have access to that pastebin? o.o
[20:19] <mgrandi> paste it to http://bpaste.net/
[20:22] <nessita> mgrandi: http://bpaste.net/show/wZE5C8kTsVdfug6caW0l/
[20:23] <mgrandi> what command are you running on it?
[20:26] <jf_> hi, I need help: I need to merge an already merged branch, because I mad some bad choices the first time.
[20:27] <mgrandi> merge it into waht
[20:28] <jf_> let me explain: in my branch b1 I did: bzr merge b2, I delete some good codes, commit, push, code,  commit, code commit, push
[20:28] <nessita> mgrandi: bzr st
[20:28] <jf_> a know I would like to resurect the good code
[20:28] <jf_> and now*
[20:28] <mgrandi> jf_: can't you just uncommit the commit that was the merge?
[20:29] <mgrandi> and nessita yeah that shouldn't happen, some of the other more experienced developers should help you, as i cant figure out whats going on just in that stack trace
[20:29] <jf_> mgrandi, why not I'm open ! but how ?
[20:30] <mgrandi> if the merge was the last commit you made to the branch, you should just be able to do 'bzr uncommit
[20:30] <jf_> the merge wasn't the last commit
[20:30] <jf_> after my mistake I commited some good codes I don't want to loose
[20:32] <mgrandi> hmm, this is more compliated now
[20:32] <jf_> mgrandi, yes that's why I'm here !
[20:35] <mgrandi> you might have to make a diff of the revisions that you want to keep
[20:35] <mgrandi> and then uncommit the merge, and then reapply the diffs
[20:35] <mgrandi> im not sure if you can shelve already commited changes
[20:35] <jf_> palying with "bzr diff" and "patch" ?
[20:35] <jf_> and how to uncommit the merge ?
[20:37] <mgrandi> http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking
[20:37] <mgrandi> actually that might work
[20:37] <mgrandi> (make a backup of your branch before you try any of these)
[20:37] <jf_> ok thanks !
[20:37] <mgrandi> i THINK this will put your branch back at like, revision 9 (in that example)
[20:38] <mgrandi> but leave the stuff that is about to be commited into revision 10
[20:38] <mgrandi> so you do that twice and then uncommit the merge i beleive
[20:38] <mgrandi> also see http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html
[20:39] <mgrandi> i have to go eat now, brb
[20:40] <jf_> thanks for your help
[22:32] <Noldorin> http://pastie.org/4274394 -- anyone know what's up here??
[22:32] <Noldorin> weird error
[22:34] <fullermd> What's weird about it?
[22:34] <Noldorin> fullermd: i have no prob pulling from lp normally :P
[22:36] <fullermd> Well, it's all at the login level, so...
[22:36] <Noldorin> why does it even need to login?
[22:36] <Noldorin> for a simple co
[22:36] <fullermd> 'cuz nobody's implemented anonymous ssh, I presume.
[22:37] <Noldorin> oh
[22:37] <Noldorin> heh
[22:44] <mwhudson> actually i have, but it was a venomous hack and i didn't propose it for merging :-)
[22:45] <jelmer> hah, there is an adjective I hadn't seen used in combination with "hack" before
[22:47] <fullermd> Sounds like the sort you'd normally apply when talking about a person.  Behind their back, I'd hope...