[02:18] <spm> ftr, I <3 $bzr log -l <number> <== that is all
[03:24] <simX> Can anyone help me with the configuration of an external merge tool in bzr 2.5?
[03:35] <simX> … :(
[04:02] <mwhudson> spm: $ bzr alias sl
[04:02] <mwhudson> bzr alias sl="log --short -l 10"
[04:02] <spm> mwhudson: but that would getin the way of sl(1)!!!!
[04:02] <mwhudson> ah yes, i guess you already have conditioning around those letters
[04:02] <spm> I can't forgo my train
[04:06] <simX> bzr is giving me a "Option this is not defined while expanding" error when setting the cmd for an external merge tool.  What's the deal?
=== yofel_ is now known as yofel
[07:50] <LarstiQ> simX: what version of bzr, and what are you doing?
[08:00] <mgz> morning all!
[08:02] <simX> LarstiQ: 2.5.0, and all I'm doing is reading the config cmd I set.
[08:02] <simX> bzr config --scope=bazaar bzr.default_mergetool=MyCoolMergeTool
[08:02] <simX> bzr config --scope=bazaar bzr.mergetool.MyCoolMergeTool="mycoolmergetool --wait \"{this}\" \"{other}\" \"{result}\" \"{base}\""
[08:02] <simX> Those seem to succeed.
[08:02] <simX> But then I do this: bzr config bzr.mergetool.Kaleidoscope --scope=bazaar
[08:03] <simX> And it gives me "bzr: ERROR: Option this is not defined while expanding "'mycoolmergetool --wait "{this}" "{other}" "{result}" "{base}"'"."
[08:03] <LarstiQ> simX: that sounds like {this} is not expanded for some reason
[08:03] <simX> Well, yeah, but why not?
[08:04] <simX> I'm just setting the mergetool cmd and reading it back.
[08:04] <LarstiQ> simX: looking at the code now
[08:04]  * LarstiQ has never set a mergetool before
[08:04] <simX> Me neither, thus I thought I was doing something wrong. :(
[08:07] <LarstiQ> simX: it sounds like a bug
[08:07]  * bialix waves on mgz
[08:07]  * fullermd waves on bialix waving on mgz.
[08:08] <LarstiQ> ah
[08:08] <bialix> hi fullermd!
[08:08] <simX> LarstiQ: As in, you think the merge tool should work and its just incorrectly giving me the error when reading the cmd back, or the merge tool cmd setting actually won't work?
[08:08] <LarstiQ> simX: I don't know the code well enough, but I have an idea of what might be wrong
[08:09] <LarstiQ> simX: based on the traceback that we get
[08:09] <simX> Ah.  Where should I file a bug, then?
[08:10] <LarstiQ> simX: I'm checking bzr 2.4 to confirm my hunch
[08:10] <simX> Alright, thx for the help!
[08:11] <LarstiQ> simX: So, I _think_ that the (new) config expanding of {option} is conflicting with the pre-existing mergetools expansion
[08:12] <LarstiQ> simX: do you want to file the bug, or shall I/
[08:12] <simX> I'm happy to file the bug myself, but it sounds like you might be able to add a little more info/context, so maybe you'd be better off doing it.
[08:13] <simX> Do you see any possible workaround?
[08:14] <LarstiQ> simX: not yet, let me dig some deeper
[08:22] <mgz> lwn scares the crap out of me for no good reason again
[08:22] <LarstiQ> mgz: how so?
[08:23] <mgz> they really should pick headlines, and which third party articles to highlight, more carefully
[08:23] <LarstiQ> simX: I don't see a workaround :/
[08:23] <LarstiQ> mgz: the google article?
[08:23] <mgz> "Google guilty of infringement in Oracle trial" ... is not actually the case
[08:23]  * simX Incredible sadness. :(
[08:23] <LarstiQ> simX: well
[08:23] <LarstiQ> simX: you could use bzr 2.4..
[08:24] <simX> 2.5 bug?
[08:24] <LarstiQ> simX: yeah
[08:24] <mgz> quoting the config file might be a workaround if that's it LarstiQ?
[08:25] <LarstiQ> mgz: how does one do that?
[08:25] <mgz> how does str.format normally want {} escpaed...
[08:25] <LarstiQ> mgz: the issue is that config.py tries to expand {this}, instead of letting mergetool do it
[08:25]  * mgz hasn't actually needed to do that
[08:26] <mgz> ah, or blast, config doesn't use str.format but its own thing
[08:26] <mgz> which probably doesn't have escaping support
[08:27] <mgz> need vila, but french holiday today
[08:27]  * LarstiQ nods
[08:27] <LarstiQ> I'll file the bug anyway
[08:28] <simX> Thanks.  So it basically means 2.5 is a no-go for external merge tools?
[08:28] <mgz> looks like {{new}} might work?
[08:29] <LarstiQ> mgz: didn't work for me
[08:29] <mgz> darn.
[08:29] <mgz> okay, so that should, which is one bug, and merge tools shouldn't clash, which is another
[08:30] <LarstiQ> simX: Imo this warrants a bugfix release for 2.5, but at the moment, it looks like that :/
[08:31] <simX> :\
[08:31] <fullermd> Probably due for one when it gets fixed anyway.
[08:33] <simX> LarstiQ: Welp, toss me a link to the bug once you've filed it, so I can track it?
[08:33] <fullermd> Not all that much has happened, but it's been a couple months...
[08:33] <LarstiQ> simX: will do
[08:34] <LarstiQ> mgz: _expand_options_in_string: # We need to iterate until no more refs appear ({{foo}} will need two iterations for example)
[08:34] <LarstiQ> mgz: so not sure about that one
[08:35] <mgz> right, that's what I was reading
[08:39] <LarstiQ> simX: bug 996401
[08:39] <ubot5> Launchpad bug 996401 in Bazaar "mergetool config clashes with config option expansion" [High,Confirmed] https://launchpad.net/bugs/996401
[08:39] <LarstiQ> mgz: is it polite to assign this to vila?
[08:41] <mgz> we don't generally work that way, but I can bug him about it tomorrow which should do
[08:41]  * LarstiQ nods
[09:18] <simX> One more quick question: to actually get bzr to use the specified external merge tool, I have to install a plugin like qconflicts?
[09:20] <vila> simX: nothing is really broken, 'bzr config <option>' want to display the value bzr will use. But in this specific case (a config template), the additional options are provided when the template is used so the error is "valid"
[09:22] <simX> vila: Yeah, saw the updates in the bug.  Thanks.
[09:23]  * simX Still a bit confused on how to actually get the external tool to launch, though.  Is qconflicts necessary?
[09:23] <simX> Grr.. keep accidentally sending msgs as actions...
[09:23] <vila> simX: as for your last question, there should be an option to chose the mergetool you want to use but I can't remember it offhand
[09:24] <simX> I can't seem to find anything in the documentation. :(
[09:24] <vila> file a bug for that
[09:25] <simX> I've set the *default* merge tool, but I merged a branch and got conflicts, now not sure how to even launch the default tool automatically on the various files.
[09:26] <vila> ha, can't help there, I don't use it myself ;-/
[09:28] <vila> simX: bzr.default_mergetool and yes, qconflicts seems to be the way to use it
[09:28] <jave> im having memory problems with bzr. ive tried several different bzr versions, so either the problem is in my repo, or in my os install
[09:29] <jave> I use the fedora 17 prerelease, which has python 273
[09:44] <LarstiQ> jave: what kind of problems?
[09:45] <LarstiQ> vila: thanks for the update!
[09:45] <jave> LarstiQ: well, in a merge from upstream, or a commit, bzr keeps allocating memory until my 6GB ram is exhausted
[09:45] <LarstiQ> jave: ouch
[09:46] <LarstiQ> jave: are large files involved?
[09:46] <jave> this is the emacs repo, so no big files
[09:47] <mgz> it's a pretty big repo... but not 6GB big
[09:47] <jave> ive tried bzr 2.4, 2.5, 2.6
[09:47] <jave> yes its a big repo
[09:48] <LarstiQ> might it be trying to repack?
[09:48] <jave> but im not doing anything fancy
[09:48]  * LarstiQ  attempts a testcommit 
[09:48] <jave> repack?
[09:49] <mgz> jave, pastebinning, or posting to the mailing list, the tail of your .bzr.log where you run out of memory would be useful
[09:49] <jave> mgz: ok
[09:50] <LarstiQ> jave: once in a while bzr tries to gather smaller packs in larger ones
[09:50] <jave> LarstiQ: can I tell it not to?
[09:51] <mgz> vila: (should be holidaying but...) what I don't understand from what you've said is if just setting the right string in the config file should still work, as you appear to imply that but LarstiQ tested a bunch of stuff and couldn't get merge tools working on 2.5 at all
[09:51] <LarstiQ> mgz: I didn't test the mergetool functionality itself, just the reading back
[09:51] <jave> also I dont care about disk size efficiency, can I get bzr to trade disk efficiency for time efficiency?
[09:51] <vila> what I said is that 'bzr config <option>' can't expand, nothing about the rest ;)
[09:52] <LarstiQ> mgz: and for the reading back, {{this}} doesn't help
[09:52]  * LarstiQ will test mergetools functionality once he figures out how to use it
[09:52] <LarstiQ> jave: not that I know, but you can `bzr pack` yourself, if that is the problem
[09:52] <LarstiQ> jave: I admit to shooting in the dark
[09:52] <vila> i.e. you can't make 'bzr config <option>' succeed, but the template *is* valid and will be populated at the right time
[09:53] <LarstiQ> jave: the other long shot that comes to mind is if you're not using the C extensions, but just pure-python
[09:53] <LarstiQ> vila: right
[09:54] <LarstiQ> jave: fwiw, I managed to commit a revision 108158 on my copy of emacs trunk. And my laptop has 700mb ram
[09:55] <vila> LarstiQ, mgz: in the general case, expansion should occur by default. Templates are the exception and you must use stack.get('xxx', expand=False) and *then* call stack.expand_options(template, {'this': 'xxx', 'other': 'yyy'})
[09:56] <LarstiQ> vila: and it's also possible to configure a template with bonafide option expansion?
[09:56] <vila> yes
[09:56] <LarstiQ> I see
[09:57] <vila> the additional 'env' parameter to expand_options takes precedence but other references will still be expanded
[09:57] <jave> LarstiQ: would you mind trying the branch in question?  bzr+ssh://bzr.savannah.gnu.org/emacs/xwidget/
[09:58] <vila> LarstiQ: also, keep in mind that mergetools was introduced while the new config scheme was designed/implemented so it suffered from lacking features at the time and Gordon did his best
[09:58] <LarstiQ> vila: aye
[09:59] <vila> LarstiQ: i.e. if this was rewritten *today* the resulting code should be simpler
[10:00]  * LarstiQ nods
[10:00] <LarstiQ> vila: would it make sense to implement the templating in terms of the config option expansion?
[10:00] <LarstiQ> if someone were interested in that
[10:01] <LarstiQ> jave: branched, trying a commit
[10:01] <vila> LarstiQ: totally
[10:01] <vila> it's on my radar but pretty low on my TODO list :-/
[10:01]  * LarstiQ nods
[10:02] <LarstiQ> vila: I might want to do some bzr hacking in a couple of weeks
[10:04] <vila> LarstiQ: you're welcome ;)
[10:04] <LarstiQ> jave: `bzr merge ../emacs; bzr resolve --all; bzr ci -m "test test"` completed
[10:04] <jave> hmm
[10:05] <jave> thanks LarstiQ
[10:05] <jave> LarstiQ: which bzr and python version do you use?
[10:06] <LarstiQ> jave: lp:bzr and python 2.6 from Debian testing
[10:07] <LarstiQ> jave: does your current .bzr.log have some useful info?
[10:07]  * LarstiQ needs to lunch, bbl
[10:14] <vila> LarstiQ: 'bzr resolve --all' is EVIL, use --take-this or --take-other but '--all' just blew up the conflicts without any attempt to properly resolve them (it really is a last-resort-everything-is-broken-restore-some-sanity option)
[10:15] <fullermd> Sanity is overrated.
[10:37] <simX> LarstiQ, mgz, vila: BTW, got the mergetool to work in 2.5.  Seems actually using the tool is fine, just reading it back using the `bzr config` throws the error.
[10:38] <mgz> simX: great, that's what was unclear to me. could you post a short summary of what you needed to get it working to your question?
[10:39] <simX> Yep, sure.
[10:43] <simX> mgz: Done.
[10:44] <mgz> ace.
[10:45] <LarstiQ> vila: I know that, but I don't know the emacs code and didn't care about the conflicts. Just wanted to see if I'd get a MemoryError
[10:46] <LarstiQ> simX: cheers! I get as far as qconflicts claiming none of the mergetools exist
[10:57] <vila> LarstiQ: ok, sry for the knee-jerk reaction but '--all' should die ;) And feedback on --take-{other,this} in hostile envs *highly* welcome !
[10:58] <vila> LarstiQ: as in: this *should* work and I think I fixed all known bugs there so new ones should be rare and fixed too
[11:07] <LarstiQ> vila: I would normally use it to signify I handled all conflicts. It looks like --done can do that job now?
[11:30] <vila> LarstiQ: yup, there is still work to be done to mark more conflicts resolved when the user already took the appropriate actions
=== Ng_ is now known as Ng
=== zyga_ is now known as zyga
[18:44] <lifeless> wgz: hi ?
=== zyga_ is now known as zyga
[21:05] <bsd> Can anybody tell me how to undo a rename detected by an 'bzr mv —auto' (or 'bzr mv —after a b')?
[21:07] <bsd> …without losing the original rename, of course.
=== wilx_ is now known as wilx
[21:33] <fullermd> mv it bak?
[21:33] <fullermd> Or back, even.
[21:59] <bsd> fullermd: hmm, that would lose the original rename.  Using —after might have worked but it throws an error