[00:11] <jelmer> Noldorin: there's a new bzr-git release (0.6.5) from a couple of days ago
[00:13] <wgz> no bed quite yet, better do travel now.
[00:14] <poolie> wgz, it doesn't have to be right now
[00:14] <wgz> will save round trips in the morning :)
[00:15] <poolie> by 'today' i meant my today, friday
[00:28] <wgz> it's done/
[00:29] <wgz> and my sis is still on the phone, so I'd not have got the extra sleep anyway :)
[00:38] <Noldorin> jelmer, oh does that fix the issue i was having with my branch though?
[00:41] <jelmer> Noldorin: no, that issue is still open
[00:41] <Noldorin> jelmer, ah, oh well...
[00:41] <Noldorin> targeting it soon?
[00:41] <Noldorin> i guess it's good news the project is still moving...thought this was a pretty crucial issue though
[00:48] <jelmer> Noldorin: your repository is the only I've seen it with so far
[00:49] <jelmer> Noldorin: it's on my list of things to work on, but I'm swamped by other stuff at the moment
[00:55] <Noldorin> jelmer, heh okay sure
[00:55] <Noldorin> jelmer, very surprising, since i isolated quite a simple reproduction case :-)
[00:56] <Noldorin> jelmer, but clearly you haven't forgotten...thanks
[00:56] <Noldorin> brb
[01:08] <poolie> GRiD, ok that still sounds pretty good then
[01:10] <GRiD> ok cool. the bzr-search change should be pretty easy too, i think. i can look at that after if i get a minute.
[01:11] <GRiD> well, easy in that i would just skip the key it's trying to add if it's too big, although i don't know if that's the right thing to do
[01:13] <poolie> i guess the question is why is the key getting so big
[01:13] <poolie> if it's just encountered a really long whitespace-delimited "word"
[01:13] <poolie> then skipping it would be reasonable
[01:13] <poolie> i don't know if that is actually the cause
[01:19] <GRiD> yeah i didn't have a chance to investigate that. but if you try to reproduce the original bug (by indexing ubiquity) with my patch, it now excepts on a key that is about a 4k (iirc) string of hex characters
[01:21] <GRiD> fwiw, if the long keys are skipped (which one of my early patches did silently), the indexing of ubiquity completes and seems to be usable.
[01:27] <poolie> GRiD, ok, so i think the main thing here is that the decision to skip is a policy of bzr-search, not bzr core
[01:27] <poolie> search may not care about indexing long strings but for other things that might lose data
[01:30] <GRiD> yep, agreed. i only meant it in that if bzr-search caught the exception and simply skipped for now (perhaps with warning), it may be sufficient. if it's not, someone who knows more about bzr-search should take a look.
[01:30] <poolie> i think that'd be good
[01:30] <poolie> thanks for fixing it
[01:30] <poolie> lifeless, ^
[01:31] <lifeless> yah, I've been following along
[01:31] <lifeless> all sounds good to me
[01:32] <GRiD> ok i'll take a look at making bzr-search skip then.
[09:15] <mgz> morning!
[11:20] <mgz> hm, it's good to know someone else is interested in maintaining paramiko, but looking at the changes 'bitprophet' has on github doesn't fill me with confidence
[11:23] <mgz> the only significant changes seem to be the rename (to 'ssh'... which seems unwise) and changing all the copyright headers(!)
[11:23] <mgz> and has done two releases to pypi without updating NEWS or otherwise indicating what's different as far as I can see
[11:33] <jam> mgz: well, having an official release channel is what we are after. We've written a few patches that have just gone ignored for long stretches of time.
[11:33] <jam> I agree that the 'ssh' thing seems a bit wonky. There can be many ssh libs around, having a unique name is nicer. Though maybe just a namespace "from paramiko import ssh"
[11:34] <jam> or 'import paramiko_ssh as ssh"
[11:35] <mgz> anyone know if github lets you issue pull requests for other people's branches?
[11:35] <mgz> ...not that they'll let me sign in, no openid support and demand js enabled.
[11:39] <jam> mgz: if you had an account, you could always 'fork' the other person's branch and propose it directly, so I would think they would allow you to propose someone elses' branch
[11:47] <mgz> jam: on your running tests against implementations in different languages thing,
[11:47] <mgz> (I don't know why but was thinking about that before going to sleep last night)
[11:48] <mgz> what people generally do is structure the cases as data as far as possible, then just write the bits they need for the runners in python/js/etc
[11:49] <mgz> eg htmllib5
[11:51] <jam> mgz: sure, but it means implementing a test-suite runner in each language
[11:51] <mgz> or it's nearly what bt.test_conflicts.TestParametrizedResolveConflicts is
[11:51] <jam> which may not be much better than implementing a test-suite in that language
[11:51] <mgz> yeah, and when you get to the point where it's nearly a mini functional language, the tests aren't very easy to read
[11:51] <jam> so far, it seems the only way if we want to ensure the *same* tests get run in each language
[11:52] <jam> mgz: we just need to port the python interpreter to vala, js, java, etc, and we'll be golden
[11:52] <jam> php will be fun :)
[11:52] <mgz> but there's probably a middle ground where the test cases are still easy enough to write, but the runners don't need to be overly complicated
[12:01] <jam> mgz: I think you meant "forwarding our existing patches" not "forwarding out existing patches".
[12:01] <mgz> ...I did
[12:02] <mgz> the keys are like, right next to each other.
[13:54] <mgz> okay, let's do the github dance
[14:09] <mgz> ha, and I don't actually have git installed here, have just been using bzr-git
[14:11] <jelmer> mgz: bzr-git should work for pushing too..
[14:11] <jelmer> :)
[14:13] <mgz> I need to do a couple of merges and thought I'd try the vanilla option first :)
[14:46] <mgz> I need to go out briefly, will be back shortly
[15:31] <mgz> back.
[16:09] <daveb_> how do I undo a merge? I want to merge from the same branch, I just wan't to do it later
[16:09] <mgz> `bzr revert`
[16:10] <mgz> if you have changes in your tree you want to keep, it's a bit harder
[16:10] <mgz> but you can tell bzr to forget the merge then undo the merged changes manually
[16:12] <daveb_> I thought revert only changed the working directory
[16:14] <mgz> it also forgets merges if you don't give specific paths, see `bzr help revert` for more.
[16:14] <fullermd> The fact of a pending merge is an attribute of the working tree.
[16:18] <daveb_> i commited the merge
[16:18] <fullermd> And other stuff since then?
[16:21] <mgz> if you haven't done other stuff, can use `bzr uncommit` then my earlier advice, otherwise you're better off... doing something clever fullermd will tell you about
[16:21] <fullermd> Oh great.  No pressure, right?
[16:22] <mgz> you're the super sub :)
[16:23] <mgz> can sit out most of the game but expected to sometimes come on and produce miracles.
[16:23] <daveb_> ok, uncommit followed by revert worked :)
[16:23]  * fullermd takes the credit.
[16:24] <mgz> see, this match we won anyway, so you just get to rest. :D
[16:24] <fullermd> Nono, too late!  You already made me cross the sideline!
[16:27] <daveb_> i guess you also have to rm -rvf any remote branches you have been pushing too...
[16:27] <fullermd> Or push --overwrite 'em.
[16:28] <mgz> only if you pushed that last change with the merge you didn't want
[16:28] <mgz> for very public locations, it's most polite to work on from mistakes, rather than trying to pretend they never happened
[16:30] <daveb_> hmm
[16:57] <fullermd> Oh no, the shame is bad enough he had to change his name.
[17:25] <croepha> lol
[18:10] <jimis> jelmer: no need to pass a source branch revno to bzr log, it should print it so we can use it with other commands, like diff
[18:10] <jimis> bzr diff -rrevno:115532:tree1
[18:10] <jimis> for example
[18:12] <jimis> bzr log should just display an extra line for each merge operation: "source branch revno: 115532"
[18:12] <jimis> in case it is expensive it should happen only with bzr log -n0
[18:17] <jelmer> jimis: that revno is specific to the source branch
[18:17] <jelmer> jimis: so you have to pass in the source branch somehow
[18:18] <jelmer> jimis: the revno displayed by log is already usable in e.g. diff
[18:18] <jelmer> bzr diff -r13423.32.1
[18:19]  * jelmer -> weekend
[20:17] <slangasek> jelmer: if and when you have some time, I could use some help with (modifying) bzr-rewrite
[21:09] <ccxCZ> I have bound branch, I did local commit and then bzr up, now the revision of the local branch was set back, how would I find the commit and push it?
[21:13] <fullermd> The local commit is now a pending merge.
[21:16] <ccxCZ> it was aggregated with uncommited changes
[21:17] <ccxCZ> I would prefer to have them as two separate commits
[21:18] <ccxCZ> I seem to be able to get the revid via bzr heads --all
[21:25] <ccxCZ> backing up working tree, updating to revid and restoring did the job