[04:22] <workthrick> bzr: ERROR: Invalid url supplied to transport: "sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/": local urls must start with file:///, UNC path urls must start with file://
[04:22] <workthrick> any idea why that happens?
[04:22] <workthrick> http://pastebin.com/V6HeubrE is a fuller output
[04:23] <workthrick> this is on win32, and it worked before
[04:23] <workthrick> (but the local repo and working tree has since been recreated)
[04:24] <workthrick> also previous colo-sync-from which I used to create the repo worked fine
[04:25] <workthrick> oh, hmm
[04:25] <workthrick> light checkout root: .
[04:25] <workthrick>    checkout of branch: sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/
[04:25] <workthrick> this is wrong, it should be .bzr/branches/gtk
[08:22] <gour> morning
[08:23] <gour> i'd like to use bzr for git-based project and wonder if 'explorer' will use dpush when i push to github or i've to use cli?
[08:24] <AuroraBorealis> what is dpush? :o
[08:25] <gour> AuroraBorealis: from the help "Purpose: Push into a different VCS without any custom bzr metadata."
[08:26] <AuroraBorealis> you can run a 'custom command' in explorer
[08:26] <AuroraBorealis> or just use the  command line if it doesn't have a explicit option to dpush
[08:26] <gour> ok
[08:46] <gour> i dpushed my branch to the github, but i do not see it listed at github which still shows only original braches from the forked repo
[08:47] <gour> i created shared repo, pull from github. created 'feature' branch locally and pushed back to github...what am i missing or how to use 'feature branch' workflow to contribute to github project?
[08:48] <AuroraBorealis> feature branch is just a trunk branch inside a shared repo
[08:49] <AuroraBorealis> not a trunk branch but just some branch inside a shared repo
[08:49] <AuroraBorealis> so you just dpush the branch to github i guess :o
[08:50] <gour> right...i cloned pulled-ed github branch in order to work on it and wanted to push it back (afer commiting some fixes)
[08:50] <AuroraBorealis> so you would probably dpush that back
[08:51] <gour> but that 'new' branch (named as 'doc-fixes') was dpushed back to github, but it's not listed there :-/
[08:51] <AuroraBorealis> maybe it takes a minute?
[08:51] <gour> hmm
[08:52] <AuroraBorealis> wait like 20 min then try again i guess
[08:52] <AuroraBorealis> or maybe dpush is bugged or something o.o
[08:53] <gour> i believe it's something else...like some github idiosync...
[08:54] <gour> hopefully jelmer or someone experienced with bzr-git & github will appear
[08:55] <AuroraBorealis> heh.
[12:11] <gour> what is the status of colo-branches in bzr? are they going to appear in 2.4?
[12:21] <d_ed> heya, I'm new to bzr. (coming from git) and can't find out the name of the command I want to do the follow
[12:21] <d_ed> Ive made some commits in a branch
[12:21] <d_ed> i want to remove one of them
[12:21] <d_ed> (like gits, interactive rebase, and not pick one of the commits)
[12:21] <d_ed> is this possible?
[12:22] <gour> in same file?
[12:23] <d_ed> yeah
[12:23] <d_ed> if it's not trivial, I'll just sort something out by hand
[12:25] <gour> maybe you can try withe shelve
[12:27] <d_ed> it's alright. I'll make a new branch then apply patches of the parts I do want
[12:27] <d_ed> *new branch from master
[12:28]  * gour is usung fossil atm considering to switch to bzr
[12:28] <d_ed> it's so hard trying to switch betweem RCS systems
[12:28] <d_ed> I'm normally on git, except for one project, and I'm sure bzr is just as good, but it's nonetheless different
[12:29] <d_ed> and that gets so confusing
[12:29] <d_ed> especially when the same word mean different things
[12:29]  * gour thinks git is too complex
[12:29] <gour> fortunately, there is fast-import machanism to switch
[16:20] <mgz> `hg clone -b 2.7 . 2.7` ...that looks a little funny
[16:20] <LarstiQ> d__ed: you can use the bzr-rewrite plugin
[16:21] <LarstiQ> mgz: what does that mean?
[16:21] <LarstiQ> mgz: clone the branch/tag called 2.7 from the current dir to the dir 2.7?
[16:22] <mgz> yup. I'm not sure the way the cpython repo is structured really makes sense to me.
[16:22] <mgz> but then, neither does what mercurial calls branches.
[16:23] <mgz> can't work on bzr without a newer python now though, and no point testing against my rusty svn copy.
[16:24] <mgz> larstiq: getting to merging the rest of my test cleanup branch which should reduce the number of things to file bugs about for pypy support
[16:25] <mgz> ha... and that mercurial command did the wrong thing, created the working tree in the cwd rather than the 2.7 dir
[16:25] <mgz> perhaps branching into a subdir upset it.
[16:26]  * LarstiQ blinks
[16:26] <LarstiQ> mgz: possibly :)
[16:26] <LarstiQ> mgz: and yay test cleanup \o/
[16:26] <mgz> ...now it's got a working tree in both dirs. probably just overwrote the no trees setting.
[16:28] <LarstiQ> mgz: about things failing on pyp, as you know the multi byte codec test fails. Not very surprising considering https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py
[16:29] <mgz> heh.
[16:29] <LarstiQ> mgz: I didn't manage extracting a small example from bzr to disprove Armin's assumption there
[16:29] <mgz> well, he's wrong
[16:29] <LarstiQ> I guessed as much :)
[16:30] <LarstiQ> mgz: and was hoping you could give me some pointers
[16:30] <mgz> the module isn't well maintained these days
[16:30] <mgz> but is likely to in use for anyone on a ckj terminal
[16:32] <mgz> various applications use streamwriters to put things on the terminal, and look at sys.stdout.encoding to create them
[16:36]  * LarstiQ generates a ja_JP.EUC-JP locale
[16:37] <mgz> ...the pypy version I have installed doesn't set sys.stdout.encoding at all, which might be why they've not got bug reports
[16:37] <mgz> or they've fixed that since 1.2.0
[16:38] <LarstiQ> mgz: it's None in my nightly from a couple of days ago
[16:38] <mgz> okay, that's the main bug then.
[16:38] <mgz> if pypy isn't detecting terminal encoding printing unicode just doesn't work.
[16:39]  * LarstiQ wonders how to test that
[16:40] <LarstiQ> my terminal inteprets the utf8 back again when I think it shouldn't
[16:40] <mgz> print u"\xa7" # or similar?
[16:41] <LarstiQ> ah, that works (as in, gives me a UnicodeEncodeError)
[16:41] <mgz> if it works, perhaps they've got the default locale set to utf-8 now?
[16:41] <mgz> ^good good.
[16:42] <LarstiQ> and it does indeed work in cpython
[16:43] <mgz> It's likely most of the unicode related tests are being skipped on pypy then.
[16:43] <mgz> see bzrlib.tests._UnicodeFilesystemFeature implementation
[16:43]  * LarstiQ hasn't been able to run the full testsuite yet
[16:44] <mgz> if we can't stat a unicode name, we don't run the test, so output bugs are probably also not being exposed.
[16:44] <mgz> one thing I do is run useful test subsets.
[16:44] <LarstiQ> mgz: I can run all the blackbox tests, off-hand I don't recall any skipped tests due to unicode feature
[16:45] <mgz> hm.
[16:45] <mgz> maybe that step now works? which would be good.
[16:45] <mgz> at least utf-8 would be being output correctly then.
[16:46] <mgz> `os.stat(u"\xa7")` on pypy 1.2.0 raises UnicodeEncodeError for me, but that may be windows only/since fixed
[16:47] <mgz> the `-s bt.test_` subset is quite good as an alternative to `-s bb.`
[16:47] <LarstiQ> mgz: gives a UnicodeEncodeError on the nightly
[16:49] <mgz> so, when I get the test cleanup stuff landed, we probably want bugs filed for all the remaining failures
[16:49] <LarstiQ> bweh, 10 seconds per test
[16:49] <LarstiQ> mgz: yup
[16:49] <mgz> ugh.
[16:52]  * LarstiQ will make an account on bugs.pypy.org in the next weeks
[16:53] <LarstiQ> mgz: thanks!
[16:53]  * LarstiQ goes cooking
[16:53] <mgz> bye!
[16:54] <gour> anyone using bzr-git with github?
[16:55] <gour> i wonder how to push my branch tobe visible at github, if possible or is it better to (as i did) import git repo to LP, use bzr and then just email 'bzr send' bundle to git-repo maintainers?
[17:00] <mgz> hm, I suspect they might prefer a plain patch. jelmer probably knows how well bzr-git works with github.
[17:00] <gour> mgz: 'send' bundle  has too much 'context'?
[17:04] <mgz> I doubt git understands the extra metadata in the bundle, they had a different method of doing the same thing.
[17:05] <gour> i just wonder what's the easiest way to submit patch(es) to git-based project by using bzr
[17:07] <mgz> it's a good question.
[17:08] <james_w> I think there is bzr send --format=git now
[17:10] <gour> i read the following in the manual: "They can also be useful when communicating with upstream projects that don’t use Bazaar. In particular, the preview of the overall change in a merge directive looks like a vanilla software patch, so they can be applied using patch -p0 for example."
[17:10] <gour> in regard to merge directives
[17:10] <gour> james_w: in 2.4?
[17:11] <james_w> I'm not sure when it was added
[17:12] <gour> sounds good
[17:16] <gour> james_w: http://bazaar.launchpad.net/~jelmer/bzr-git/send/revision/533
[18:30]  * workthrick looks around for jelmer
[20:22] <mgz> I'm having trouble resuming my collection branch from jam's partial merges
[20:23] <mgz> if I merge the current version to dev it has some of the changes that have already landed, and misses the most important bits in bzrlib.tests
[20:24] <mgz> presumably this relates to the "Warning: criss-cross merge encountered.  See bzr help criss-cross." I get
[20:24]  * gour played/used bzr after long time today....very pleased with it
[20:24] <mgz> but it's odd that the merge command lists bzrlib/tests/__init__.py
[20:24] <mgz> but bzr diff on that file is empty
[20:25] <gour> i sent test 'bundle' with git format hoping it's possible to apply it upstream
[20:25] <mgz> I think maybe what jam did works on branches where he works in his normal fashion, but something in my branch history broke it?
[20:26] <mgz> I'm not sure what the fix is then as two partial merges are already on bzr.dev