[00:10] <knighthawk> okay so I'm new to bzr but been using svn for years. Thought I understood Bzr differences but now not so sure.
[00:10] <knighthawk> I created a repos on my local machine using bzr init.
[00:10] <knighthawk> Then after a few revisions I realized I was going to need a central repos and created it with init-repo
[00:11] <knighthawk> then using bzr export I copied the files over and thought I had a central repos all set up.
[00:11] <knighthawk> I could pull from it but not commit to it.
[00:11] <knighthawk> I think because it didn't have a working tree.
[00:12] <knighthawk> so I used 'bzr update .' to create a tree in the repos
[00:15] <knighthawk> the problem is (I think) that my original branch seems to have its own repo and doesn't seem to be tracking from the central repo. So I *think* all I want to do is update something to tell my local copy to use the branch at the central repos as its trunk now.
[00:15] <spiv> You may find the "bzr info" and "bzr reconfigure" commands helpful
[00:16] <knighthawk> but I'm not *sure* that's what I want and don't know how to do it yet. (though If I'm confident that's what I want to do I'm sure I can look up the commands)
[00:16] <knighthawk> thanks spiv
[00:16] <spiv> But also I think you are confusing some concepts
[00:16] <spiv> A shared repository is independent of whether a branch/checkout is "tracking" (as you put it) another branch.
[00:17] <spiv> A shared repository, the thing you create with "bzr init-repo", is basically just a storage (and speed) optimization.
[00:17] <spiv> It doesn't actually affect the behaviour of the branches that use it.
[00:19] <knighthawk> yeah I'm not too clear about what's not working there. At first everyone could pull or checkout but no could commit and I don't think they could update from the central repo. Now that I have a working tree there that may change but it seems from what I'm reading that I shouldn't need a working tree at the shared repo
[00:25] <spiv> "bzr info" is useful for inspecting how things are connected.
[00:39] <knighthawk> okay so I think what I want to do is from my local host branch run 'bzr reconfigure --use-shared <path/to/shared/repo>'
[00:40] <knighthawk> then it seems like I don't need the working tree in the shared repo (is there any reason I should remove the tree that's there?)
[00:45] <knighthawk> When I tried that I got 'bzr: ERROR: sftp://repo/path/branchName/.bzr / is not a local path'
[00:54] <spiv> A branch can only use a shared repository in one of its parent directories.
[02:17] <knighthawk> spiv, I'm in the top level directory for the branch. (if that's what you mean)
[02:54] <spiv> knighthawk: no, I mean that if you branch is at directory /a/b/c/your_branch, then the shared repository has to be at /a/b/c, /a/b, /a, or /.
[04:51] <knighthawk>  ah thanks spiv
[04:55] <knighthawk> okay so no errors now but bzr info still says its a stand alone branch
[05:03] <spiv> knighthawk: 'bzr reconfigure --use-shared' will change that, if there's a shared repo it can use (i.e. there's one in a parent directory)
[05:10] <knighthawk> spiv, so before I was trying 'bzr reconfigure --use-shared sftp://path/to/repo/project' now I'm doing 'bzr reconfigure --use shared sftp://path/top/repo/' and like I said no errors now. but bzr info hasn't seemed to update.
[05:21] <spiv> knighthawk: You're doing 'bzr info sftp://path/to/repo/project' ?
[07:46] <vila> hi all !
[07:50] <vila> yeah for Santa Claus, best pp ever :)
[07:51] <spiv> vila: :)
[07:52] <mkanat> lol
[07:52] <vila> spiv: before you leave: enjoy your... leave :) and Happy Christmas !
[07:53] <spiv> vila: thanks, you too!
[07:53] <spiv> vila: so to leave with a bit of a negative review on one of your patches :(
[07:54] <spiv> vila: it looks like a step towards the right fix, but not yet a complete fix.
[07:54] <spiv> s/so/sorry/
[07:54] <spiv> Wow, I'm so sorry I couldn't even type the word!
[07:54] <vila> well done (reading now), if it doesn't fix it, better to catch it now :)
[07:55] <vila> ok, read
[07:56] <vila> hehe, I said it and will keep saying and thinking it, importing symbols is confusing :)
[07:56] <vila> REPORT_ONLY_FIRST_FAILURE is defined only in doctest, so it should be prefixed
[07:57] <spiv> All the more reason for consecutive lines to be consistent ;)
[07:57] <vila> DocTestSuite is redefined in bzrlib.tests and is the one we want to use so should *not* be prefixed
[07:57] <spiv> Oh, redefined with the same name?  Ew.
[07:57] <spiv> *That* is confusing.
[07:57] <vila> right
[07:57] <spiv> Rename to BzrDocTestSuite perhaps?
[07:58] <vila> should I rename it BzrDocTestSi... :)
[07:59] <vila> now, whether this fix 321320 is a bit blurry, it *fixes* the issue with brnchbuilder as EMAIL is now set correctly, but HOME is still problematic
[07:59] <vila> more broadly, setting evn vars to None is always ok, setting them to specific values is always tricky
[08:00] <vila> I think I said that in the comments, but you rightly point that we have been wrong with HOME
[08:00] <vila> so coming back the beginning of the discussion: I see nothing negative here :)
[08:01] <spiv> It doesn't fix the branchbuilder issue for me: it still executes gnome-gpg, as specified by my ~/.bazaar/bazaar.conf
[08:01] <vila> yup
[08:01] <vila> my bad, I don't encounter the issue and failed to check it
[08:02] <spiv> To be fair it helps, because HOME is now set to the cwd rather than my actual HOME
[08:02] <spiv> But sometimes my cwd == $HOME :)
[08:02] <vila> yup, that's wrong anyway
[08:02] <spiv> (Also there are other ugly side effects like spewing .bzr.log into odd places)
[08:03] <vila> still ???
[08:03] <spiv> Well, into the cwd
[08:03] <vila> doctests spew .bzr.log files ??
[08:03] <vila> suspicion or fact ?
[08:03] <vila> grr, two different threads
[08:03] <vila> did you see .bzr.log files ?
[08:03] <spiv> vila: Well, when my cwd == $HOME, the tests wrote to my ~/.bzr.log
[08:03] <vila> bah, I can check that
[08:04] <vila> hmm
[08:04] <spiv> Hmm, but apparently not to the other dir I tried?
[08:04] <spiv> Odd.
[08:05] <vila> anyway, mgz + spiv 1 - 0 vila, back to drawing board :)
[08:05] <spiv> Anyway, set HOME to a temporary dir in doctests and I'll stop caring :P
[08:05] <vila> yup
[08:05] <vila> mgz was asking for roughly the same thing in different words
[08:05] <spiv> It may mean pulling out more of the isolation code into functions
[08:05] <vila> exactly his words :)
[08:06] <spiv> Oh, and your branch isn't linked to the bug!
[08:06]  * spiv just noticed
[08:06] <vila> I resisted a bit because doctests use setUp/tearDown, no way to have a addCleanup there
[08:06] <vila> haha freudian slip !
[08:07] <spiv> Ok, EOD and EOY for me here.
[08:07] <spiv> FWIW I think addCleanup is possible
[08:07] <vila> thanks for the review and the discussion !
[08:07] <spiv> You could build it with bzrlib.cleanups perhaps
[08:07] <spiv> But, really gone now :)
[08:07] <vila> yeah, no *easy* way to have
[08:26] <vila> wow, setting HOME to None doesn't annoy our test suite *at all*...
[08:27] <vila> I wonder if... it doesn't get set by some lower level layer though... or what will happen on other OSes...
[08:39] <AfC> vila: you have no $HOME
[08:40] <vila> yeah, looks like Linux is friendly with the homeless ones, why am I not surprised :)
[08:40]  * vila runs it on babune to see how other OSes consider homeless tests :D
[08:41] <fullermd> That's not really homeless, though, it's only virtually homeless.
[08:42] <vila> fullermd: is this just a joke or are you trying to convey some intuition there ? HHOS
[08:43] <vila> I find it hard to believe that you can run that much code without HOME being set...
[08:44] <vila> but I can't deny successful test either...
[08:44] <vila> testS even, ~24000 and some
[08:44] <fullermd> Well, what's it need $HOME for, anyway?  Just looking up bazaar.conf and plugins, neither of which it needs?
[08:44] <vila> for bzr itself, yes, but no other lower level stuff ?
[08:45] <vila> no unix centrism at all ? Nowhere ?
[08:47] <vila> .bzr.log in addition to plugins and config files, may be apport stuff too...
[08:47] <vila> but apport is disabled most of the time and .bzr.log files... may handle being homeless
[08:50] <fullermd> Actually, doesn't the test suite override $HOME for that stuff anyway?
[08:53] <spiv> Almost all the test suite overrides $HOME, yeah.  Off the top of my head the only bits that don't are doctests, and vila's fixing that...
[08:53] <vila> fullermd: that's the issue I'm looking at, it wasn't for the doctests, now it does (in a pending submission), I changed it to make HOME == `pwd` and spiv raised some valid concerns when pwd == $HOME (the real one)
[08:53] <vila> so I tried setting HOME to None (aka deleting it from os.environ) and wow, it passes
[08:54]  * spiv isn't really here, of course.
[08:54] <vila> I think I will set it to some tmp dir, just because it's... scary , but the experiment is worth a try
[08:55] <vila> nothing beats what the English expression for demonstrating something by checking that the opposite is absurd ?
[08:55] <glyph> Hey #bzr-ers
[08:56] <glyph> I'm happy these days using bzr as a Subversion client, I hardly ever have to invoke 'svn' itself any more
[08:56] <glyph> but, increasingly I am being called upon to look at and work with repositories in Git or Mercurial, and it seems like the plugins for interacting with those are pretty primitive.
[08:56] <glyph> Which seems weird, given that as DVCSes their data models are more similar to bzr's than svn's is.
[08:57] <glyph> Is there a plan in the works for improving support for them?
[08:58] <vila> glyph: given that the plugins main author is joining the bzr team next year, I'm very tempted to say the situation can only improve...
[08:59] <bob2> vila-afk: jelmer?
[09:00] <vila-afk> bob2: himself
[09:00] <bob2> oh, cool
[09:02] <glyph> vila-afk: "next year" like "in a week, when it's january" or like "in 12 months"?
[09:02] <vila-afk> glyph: the former, but make that a month
[09:02]  * vila-afk really afk now !
[09:03] <glyph> okay that is awesome.
[09:03] <glyph> thanks for the info :)
[12:57] <mxc> hi
[12:58] <mxc> is it normal for bzr to need to send 100kb to the server to commit a change which consists ofa  single line in a single file?
[13:04] <Peng> mxc: Yeah, probably. It needs to find out what it has to send. Is it using a smart protocol (e.g. bzr+ssh, not sftp)?
[13:04] <mxc> nope, sftp
[13:04] <Peng> mxc: Oh, then that definitely sounds normal.
[13:04] <mxc> oh, ok
[13:05] <Peng> More or less. I mean, I don't know the exact usage expected, but it sounds about right to me.
[13:06] <Peng> Over a dumb protocol, it can't just ask the server "What do I need to send?", it has to go digging around in the repository's files.
[13:06] <Peng> Plus, it likely grabs more data then necessary sometimes to reduce roundtrips.
[13:07] <Peng> Anyway I'm about to pass out from hunger bbiab
[13:07] <mxc> is there anyhting dangerous if i unbind my repo and rebind to hte same repo using bzr+ssh isntead of sftp?
[13:09] <Peng> Probably not? There should be a "switch" command or such.
[13:09] <Peng> If you mean a branch rather than a checkout, just push/pull --remember.
[13:10] <Peng> Which is safe as can be.
[15:02] <tacone> hello, is there a way to have multiple push locations ? (i.e. every "bzr push" will push to 2 different locations)
[15:03]  * mgedmin would like
[15:03] <jelmer> tacone: not with stock Bazaar, there might be a plugin that does
[15:04] <tacone> i only found bzr-push-and-update but I'm not sure it's doing that. the documentation is confusing
[15:05] <jelmer> no, bzr-push-and-update doesn't provide that
[15:06] <tacone> oh, ok.
[15:06] <mgedmin> does bzr push lock the source branch?
[15:07] <jelmer> mgedmin: it should only read-lock
[15:07]  * mgedmin is considering a plugin to mirror his branches in the background, while he continues working in the foreground
[15:07] <mgedmin> so that would mean I can't bzr commit if there's a push going on
[15:07] <mgedmin> hm
[15:07] <jelmer> mgedmin: I think that should work
[15:16] <tacone> jelmer: maybe the repo-push plugin ?
[15:17] <jelmer> tacone: that pushes an entire repository, it doesn't push to multiple locations
[15:17] <jelmer> tacone: I think you'd either have to write your own or use a shell script or something like that
[15:17] <tacone> guess i'll go for a shell script. thanks
[16:26] <frathgeber> could anyone please update me what's the current status on nested subtree support in bzr? my experiments with bzr join --reference (still in beta i know) concluded that this feature isn't quite useable yet (at least for what i wanted to do)
[16:26] <frathgeber> what's the current best practice then for nested subtrees?
[16:28] <jelmer> frathgeber: nested trees are not supported yet - there are a few plugins that provide similar functionality
[16:28] <jelmer> bzr-externals being the most notable one probably
[16:31] <frathgeber> jelmer: thanks, that's what i figured from some research
[16:32] <frathgeber> problem is i want to bootstrap my dotfile configuration from a bzr repo when deploying on a new machine. and if that depends on a bzr plugin already installed it somehow defeats the point
[16:33] <frathgeber> any good idea what i could do in this case?
[17:50] <lifeless> mgz: how is testtools trunk looking to you?
[17:51] <mgz> C:\bzr\testtools>testtools\run.py testtools.tests.test_suite
[17:51] <mgz> Tests running...
[17:51] <mgz> Ran 586 tests in 2.688s
[17:51] <mgz> OK
[17:54] <lifeless> righto
[17:54] <lifeless> will do a 0.9.9 todayish
[17:54] <lifeless> hey
[17:54] <mgz> what did 0.9.8 miss?
[17:54] <lifeless> did you see I rewrote a bunch of stuff in testrepository
[17:54]  * mgz looks at the log
[17:54] <lifeless> I was wondering if if you could update your patch[es]
[17:55] <lifeless> and then I'll merge them
[17:55] <mgz> will do.
[17:56] <lifeless> mgz: 0.9.8 missed two defects in testresult.time() handling
[17:56] <lifeless> which got highlighted when testrepository started depending on it for parallel test partitioning
[17:56] <mgz> ugh, datetime is such a pain.
[17:57] <lifeless> yes, the 'no timezone' instances are BONG
[17:57] <lifeless> I really don't understand why they did that. I mean, for simple floats, time.time() stuff - understandable. But /datetime/ ?!
[17:57] <lifeless> sorry, ‽
[18:16] <mgz> ah, that's what these DocTestMatches failures are about, should have thought of it before
[18:16] <mgz> (Pdb) actual
[18:16] <mgz> "True True True\r\n['b:\\\\temp\\\\tmpgohhtz\\\\testr', 'foo bar', 'baz']\r\n"
[18:16] <mgz> it's dumb about newlines!
[18:31] <mgz> fixing the last two failures is hard, because the actual code is bad and wrong
[18:32] <mgz>     elements = [command] + list(testargs)
[18:32] <mgz>     cmd = ' '.join(elements)
[18:32] <mgz> you can't do that, it's unsafe.
[18:32] <mgz> the problem is that TestListingFixture wants a string for `self.template = cmd_template`
[18:32] <mgz> not a list, which could be used safely.
[18:33] <mgz> how much of a breaking change would it be to just fix that lifeless?
[19:21] <hazmat> just noticed bzr replaced a '!!' in my commit message with 'bzr stat' seems odd.
[19:35] <lifeless> mgz: TestListingFixture hasn't been in a release
[19:35] <lifeless> mgz: so there are no api concerns about it at all
[19:36] <lifeless> hazmat: thats your shell
[19:36] <lifeless> hazmat: almost certainly
[19:39] <zyga> lifeless, hi, is there any guide or doc about using bzr on nfs
[19:39] <lifeless> zyga: don't do it?
[19:39] <zyga> lifeless, I have a tiny standalone branch
[19:39] <zyga> several dozen KB
[19:40] <lifeless> zyga: the branch and repo formats will work fine on nfs, as they do even on ftp
[19:40] <hazmat> lifeless, indeed it is
[19:40] <zyga> bzr status on that branch takes megabytes of transfer and does not complete
[19:40] <lifeless> the working tree needs reliable operating system locks.
[19:40] <zyga> lifeless, I have nfs4 so locks should also work
[19:40] <zyga> but I worry about just not working fast enough for anything
[19:41] <lifeless> zyga: we get a constant stream of 'does not work on nfs' -> 'check your locks' -> 'oh! that works'
[19:41] <zyga> right now it's taking ~40Mbit to bzr status in that 10 file branch
[19:41] <lifeless> zyga: however, the many megs of transfer is a kernel bug
[19:41] <lifeless> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480444
[19:41] <zyga> oh
[19:41] <zyga> that's new! :)
[19:41] <lifeless> 2009
[19:43] <zyga> thanks, that at least makes the debugging operation far shorter
[19:44] <lifeless> zyga: de nada
[19:45] <lifeless> mgz: why the change in testcommand from cmd = .., repeated to daisy-changed .replaces ?
[19:46] <lifeless> mgz: I find the latter an uncommon style in python, even though its hyper-common in (say) smalltalk
[19:46] <lifeless> oh, .replace instead of re
[19:47] <lifeless> mgz: why?
[19:49] <lifeless> mgz: also, why are you not looking for bin/testr in the test_setup change?
 mgz: why? <- see latest comment and re.sub documentation

[20:04] <mgz> "repl can be a string or a function; if it is a string, any backslash escapes in it are processed. That is, \n is converted to a single newline character, \r is converted to a linefeed, and so forth."
[20:05] <mgz> so re.sub("\$BLAH", "C:\\temp", "$BLAH") -> "C:\x09emp"
 mgz: also, why are you not looking for bin/testr in the test_setup change? <- because DocTestMatches was just outright borked there
[20:06] <mgz> probably was the newline thing again, might be able to do .replace("\r", "") and revert what it's looking for.
[20:07] <mgz> ^(personally, I find chained replaces less silly than repeated assignments to the same variable, and the least worst option when not doing something one-pass fancy)
[20:10] <mgz> oh, and looking for bin/testr needed changing anyway, there's nothing binny on windows
[20:11] <mgz> the script goes in Python24\Scripts\testr or similar
[20:11] <mgz> if you tell me what that check is actually trying to confirm, I can write a portable version of it.
[20:13] <lifeless> mgz: I want to check that that some known thing - e.g. the entry point script - is shown by the setup command
[20:13] <lifeless> as a proxy for 'and setup works properly'
[20:13] <lifeless> what you made it look for is too early in the process
[20:13] <mgz> how about checking each of the "running X" steps lines exists?
[20:14] <mgz> rather than just the one I used.
[20:14] <lifeless> I want to see project data
[20:17] <lifeless> I'm not inclined to believe that setup.py's overview output tells us anything interesting about it, given failures I've seen in the past.
[20:21] <mgz> well would "    running install_scripts\n...    adding '...testr'\n..." do then?
[20:22] <mgz> otherwise need to pull something in from distutils to get the dir it installs scripts to
[20:34] <lifeless> mgz: that would be fine
[20:37] <lifeless> vila: hi
[20:39] <mgz> hurgh, and then the matcher output formatting confused me.
[20:39] <mgz> the real output doesn't have a four-space indent.
[20:57] <tacone> hello, is there any method to concatenate 2 working tree and have the second start at the end of the first ?
[20:58] <tacone> i mean the first revision of the 2nd should be the last revision of the first+1
[21:39] <nekohayo> hey there, I'd like to, say, "grab commits 2..6 from branch foo", then commit 1-2 commits, then "grab commits 8..10 from branch foo", but *without* losing the individual history of those commits
[21:39] <nekohayo> ie I'd like to keep the commit messages, author, timestamps, etc
[21:39] <nekohayo> is it possible?
[21:40] <nekohayo> sounds to me like a mix of the concepts of cherry-picking and rebasing, but I don't know if bazaar can do this
[21:41] <mkanat> tacone: I think you want "bzr join"?
[21:42] <tacone> mkanat does bzr join allow me to concatenate 2 trees consequentially ?
[21:42] <mkanat> tacone: bzr help join
[21:43] <tacone> doc is not clear to me
[21:44] <tacone> btw:  The TREE argument should be an independent tree, inside  another  tree,        but  not  part  of it.
[21:44] <tacone> seems not what i'm looking for
[21:49] <mkanat> tacone: You could make it do what you want.
[21:49] <mkanat> tacone: Unless you're talking about two trees with identical file names.
[21:50] <mkanat> tacone: In which case, AFAIK, the answer is "unfortunately no".
[21:50] <tacone> ...
[21:50] <tacone> maybe i could try to merge the rev.1 of the second tree in the first tree
[21:50] <tacone> and try to simply bzr pull
[21:51] <mkanat> tacone: I'm not sure you can merge trees that don't have anything in common. You could try though.
[21:52] <mkanat> any revisions in common, that is.
[21:52] <tacone> yes i can, i just need to handle conflicts
[21:54] <mkanat> tacone: Well, true.
[21:54] <mkanat> tacone: But the history of the files won't be merged.
[21:55] <mkanat> tacone: They will appear to be separate files, just like if you'd done join and then mv.
[21:55] <mkanat> Oh, although I suppose they don't have to be.
[21:55] <tacone> not sure
[21:55] <mkanat> You would have to do the file content merging manually, though.
[21:55] <tacone> but it really does not matter in my case
[21:55] <nekohayo> oh, maybe bundle-revisions is what I'm looking for
[21:59] <lifeless> nekohayo: perhaps you just want
[21:59] <lifeless> merge -r 6 source; commit; merge -r 10 source; commit
[21:59] <lifeless> nekohayo: however, if you want to skip a revision, you either need to back it out (as a commit) or rebase
[22:00] <nekohayo> lifeless, but then I'd lose the original commit message, author, timestamp
[22:00] <lifeless> nekohayo: merging a prefix of a branch doesn't lose metadata
[22:00] <nekohayo> huh?
[22:01] <lifeless> if a branch has 10 commits
[22:01] <lifeless> merging the first 5 preserves the revision graph, all the original data is there
[22:01] <lifeless> if you then merge the last 5, same thing applies
[22:01] <lifeless> its only if you want to skip a commit that things become cherrypicks (which is what rebases are)
[22:02] <nekohayo> yeah, the problem is that I want to skip a commit in the middle and replace it by something else
[22:02] <lifeless> so you can rebase, which will make commits that appear like the originals but have new revision ids
[22:03] <nekohayo> I thought you could only rebase "onto" something
[22:03] <lifeless> the command is called 'replay'
[22:03] <lifeless> the internal logic is that of rebase
[22:03] <lifeless> its in bzr-rewrite
[22:05] <nekohayo> lifeless, for some reason I can only find the doc page for http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.html
[22:06] <lifeless> the rebase plugin was renamed to rewrite to reflect its broader mandate
[22:07] <nekohayo> wow, replay does almost everything
[22:07] <nekohayo> except it doesn't preserve the author
[22:08] <nekohayo> (I used bzr replay -r 159..164 ../reworkd/ )
[22:08] <nekohayo> is there something like that but that keeps the author?
[22:08] <lifeless> that may be a bug, it predates the separated author facility
[22:09] <nekohayo> hm?
[22:09] <lifeless> probably fairly easy to fix - could you file a bug to start with?
[22:09] <lifeless> bugs.launchpad.net/bzr-rewrite
[22:09]  * nekohayo files a bug
[22:12] <nekohayo> filed as https://bugs.launchpad.net/bzr-rewrite/+bug/693949
[22:15] <mgz> what's the easiest way to get an interdiff in svn without actually committing...
[22:16] <mgz> probably need to copy the whole tree.
[22:16] <lifeless> difftacular
[22:17] <lifeless> or diff -r branch:/..:54
[22:17] <lifeless> oh
[22:17] <lifeless> svn... bzr import-svn :)
[22:18] <mgz> :)
[22:29] <tacone> guess my best option is to reimport manually my 13 revision on the top of the new branch
[22:31] <jelmer> nekohayo: I can't reproduce that
[22:31] <nekohayo> huh
[22:32] <nekohayo> what version of bzr rebase?
[22:32] <nekohayo> I'm using the one that came with ubuntu 10.10
[22:32] <jelmer> I'm using trunk
[22:33] <jelmer> but I don't think this part of the code has changed recently
[22:35]  * nekohayo just tried again, same result
[22:35] <jelmer> nekohayo: with trunk, or with 0.6.1 ?
[22:36] <nekohayo> 0.6.1; I'll try a bzr branch lp:bzr-rewrite into my ~/.bzr/plugins
[22:36] <nekohayo> .bazaar/plugins/ I mean
[22:37] <lifeless> bzr branch lp:bzr-rewrite ~/.bzr/plugins/rewrite
[22:37] <lifeless> nekohayo: ^
[22:38] <nekohayo> ya
[22:38] <jelmer> lifeless: s/\.bzr/.bazaar/
[22:38] <nekohayo> ok done
[22:38] <nekohayo> still seeing the bug
[22:38] <nekohayo> (I did remove bzr-rebase from synaptic to be sure)
[22:39] <lifeless> jelmer: blah yes
[22:39] <jelmer> nekohayo: did you see my reply to the bug?
[22:39] <lifeless> nekohayo: bzr plugins -v
[22:39] <lifeless> will show what plugin is being loaded
[22:39] <jelmer> nekohayo: can you paste the output of "bzr log -r -1" ?
[22:39] <nekohayo> oh I hadn't seen your comment
[22:39] <nekohayo> hang on
[22:40] <nekohayo> oh, I'm an idiot.
[22:40] <nekohayo> bzr viz shows the committer, not the author
[22:40] <nekohayo>  /headdesk
[22:41] <jelmer> hmm, I guess it would make more sense for it to show the author(s)
[22:41] <jelmer> nakohayo: feel free to retarget the bug to bzr-gtk
[22:41] <nekohayo> you mean nobody had filed a bug about this before?
[22:42] <jelmer> Not that I remember
[22:46] <nekohayo> there you go
[23:16] <jelmer> nekohayo: thanks!
[23:16] <nekohayo> jelmer, just to be sure, bzr viz is not going away is it?
[23:16] <nekohayo> I mean it won't get replaced by bzr explorer or something?
[23:16]  * nekohayo likes its simplicity
[23:22] <jelmer> nekohayo: no, it's not going away. it hasn't really had the attention it deserves recently though