[07:59] morning! [08:22] hey mgz [09:02] bug 1025030 [09:02] Launchpad bug 1025030 in Bazaar "[pipeline] bzr switch PIPENAME crashes with bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'BzrBranch5'" [Undecided,New] https://launchpad.net/bugs/1025030 [09:02] looks like something in 2.6 borked loom? [09:07] mgz: https://code.launchpad.net/~jelmer/bzr-loom/branch5-move/+merge/115302 [09:12] jelmer: approved and etc === mrevell_ is now known as mrevell [10:35] 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] YYyyup [10:37] The Linux kernel source code rarely has to rename files, so Linus didn't consider renames a core feature in git [10:37] 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] The weird thing is that GitHub actually displays it as a "rename" [10:39] anyway. [10:39] AfC: git infers renames at run-time, it doesn't store them [10:39] jelmer: yeah [10:39] [I know] [10:39] like I said, think of the poor kittens [10:40] 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] 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] AfC: I wouldn't do this with any existing branches, it will horribly break your existing users [10:45] jelmer: ok [10:45] jelmer: [just me at this point on this particular repo] [10:45] jelmer: but no, I wouldn't want to do it for a major project! :( [10:46] AfC: you should be able to get back to the old tip by using 'bzr heads --dead-only' [10:46] jelmer: no, it's cool, I have lots of versions of this branch around [10:46] jelmer: I'm experimenting [10:47] AfC: ah, great [10:47] 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] is that correct? [10:47] AfC: yes [10:47] ok [10:47] 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] 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] jelmer: I remember years ago we talked of being able to preserve metadata when pushing to [Subversion] it then was [10:49] jelmer: round tripping ... as in keeping git and bzr locally, shuttling patches locally, and using git to shuttle from local to remote? [10:49] or as in "use fast-export" [10:49] AfC: fast-export doesn't roundtrip [10:49] oh [10:49] AfC: it discards revision-ids, renames, revision properties, etc [10:49] 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] so {shrug} learning curve === nyuszika7h is now known as Guest63432 [10:54] jelmer: [am I missing something? Do we *have* round trip capability?] [10:55] AfC: no, there is no roundtrip capability [10:57] AfC: enabling git users to contribute to a codebase in bzr doesn't work particularly well at the moment [10:57] 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] 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] I could just keep using bzr [and self-hosted branches] only, but... [11:09] AfC: personally, if the community was github centric I would use git for this [11:10] AfC: it would be nice if things interoperated better, but unfortunately that's not the case at the moment === zyga is now known as zyga-afk [13:31] jelmer: hey, it's awesome what we have now. bzr-git is fantastic. [14:16] 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 === zyga-afk is now known as zyga [15:20] I'm getting "Tree transform is malformed" errors from 'bzr shelve'. [15:20] looks like this: http://dpaste.com/771792/ [15:20] is this a known bug? anything i should do to work around it? :) [15:20] missing parent? [15:20] are you..missing the parent? =P [15:21] good question. how would I check? :) [15:21] is the branch stacked or part of a shared repo? [15:22] nope, it's standalone [15:23] deryck: hmm wow, another bzr in birmingham? :) [15:23] dash, near Auburn actually :) [15:24] im not that familiar with teh bzr internals so im only guessing [15:24] ga, why did people in the US have to be so unimaginative with place naming [15:24] deryck: hah ok :) i haven't been down there since shortly after I graduated... [15:24] mgz: americans came from england and brought their place names with them! [15:25] mgz: also Birmingham was founded as a steel town. so naming after an English steel town made sense. :) [15:25] mgz, it's also not as if dash or I did the naming ;) [15:25] dash: the likely cause is you're shelving the rename/deletion of a directory with an ignored file in it [15:25] mgz: hah! ok [15:25] or something similarly finikity [15:25] mgz: I am most likely doing that. [15:25] you should be able to just not do that. [15:27] yep [15:29] dash: feel free to +affectsmetoo on bug 611739 if that was the issue [15:29] Launchpad bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside" [Medium,Confirmed] https://launchpad.net/bugs/611739 === beuno is now known as beuno-lunch [16:10] mgz: ah, thanks. === beuno-lunch is now known as beuno [16:46] is there a gratis place like github for Bazaar projects? [16:46] launchpad, or github using bzr-git === yofel_ is now known as yofel === zyga is now known as zyga-afk [20:16] 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] I'm running bzr Installed: 2.5.1-0ubuntu2 [20:18] i dont have access to that pastebin? o.o [20:19] paste it to http://bpaste.net/ [20:22] mgrandi: http://bpaste.net/show/wZE5C8kTsVdfug6caW0l/ [20:23] what command are you running on it? [20:26] hi, I need help: I need to merge an already merged branch, because I mad some bad choices the first time. [20:27] merge it into waht [20:28] 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] mgrandi: bzr st [20:28] a know I would like to resurect the good code [20:28] and now* [20:28] jf_: can't you just uncommit the commit that was the merge? [20:29] 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] mgrandi, why not I'm open ! but how ? [20:30] if the merge was the last commit you made to the branch, you should just be able to do 'bzr uncommit [20:30] the merge wasn't the last commit [20:30] after my mistake I commited some good codes I don't want to loose [20:32] hmm, this is more compliated now [20:32] mgrandi, yes that's why I'm here ! [20:35] you might have to make a diff of the revisions that you want to keep [20:35] and then uncommit the merge, and then reapply the diffs [20:35] im not sure if you can shelve already commited changes [20:35] palying with "bzr diff" and "patch" ? [20:35] and how to uncommit the merge ? [20:37] http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking [20:37] actually that might work [20:37] (make a backup of your branch before you try any of these) [20:37] ok thanks ! [20:37] i THINK this will put your branch back at like, revision 9 (in that example) [20:38] but leave the stuff that is about to be commited into revision 10 [20:38] so you do that twice and then uncommit the merge i beleive [20:38] also see http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html [20:39] i have to go eat now, brb [20:40] thanks for your help [22:32] http://pastie.org/4274394 -- anyone know what's up here?? [22:32] weird error [22:34] What's weird about it? [22:34] fullermd: i have no prob pulling from lp normally :P [22:36] Well, it's all at the login level, so... [22:36] why does it even need to login? [22:36] for a simple co [22:36] 'cuz nobody's implemented anonymous ssh, I presume. [22:37] oh [22:37] heh [22:44] actually i have, but it was a venomous hack and i didn't propose it for merging :-) [22:45] hah, there is an adjective I hadn't seen used in combination with "hack" before [22:47] Sounds like the sort you'd normally apply when talking about a person. Behind their back, I'd hope...