[00:00] TresEquis: sure. or @ http:// or webdav, etc. hrm. with a little juggling, i *could* live with one-way only ... still not ideal for the long term. but ... [00:01] * TresEquis is running live mirrors of the repoze SVN repository to each of bzr, git, and hg [00:01] mostly to say STFU to folks who want us to commit to *their* DVCS choice [00:04] TresEquis: I was hoping to say STFU to projects that want me to commit to crowbarring MY workflow to fit THEIR rcs choice ;-) [00:04] sure [00:04] SVN doesn't suck too badly as the "centralized" repo [00:05] and if everybody else can do branches, etc. using their tool of choice, then that makes SVN an "implementation detail" [00:05] sneaker-net with Hollerith field punched cards was, at times, easier .... sigh. [00:05] only those who can commit to the central repo need to care about [00:06] mwhudson: https://code.launchpad.net/~mwhudson/launchpad/code-import-workers-copy-too-much/+merge/24282 [00:06] mwhudson: did you see my note? [00:07] lifeless: yes, i meant to ask you about that [00:07] lifeless: i don't understand how it's "wrong", i can see it might be less than perfect [00:07] theres nothing that says the control dir is .bzr [00:07] oh come on [00:08] we've tried pretty hard to make it possible for loom or things like that to use different dirs [00:08] its a shame to bypass that [00:08] anyhow [00:08] if you want to use .bzr + clone, do so - but using .transport will be shorter and easier to read IMO [00:09] I guess for lp which enforces .bzr as the control dir name there are less degrees of freedom, at least at the moment. [00:09] xnox: TresEquis k. so to be clear -- as long as i'm only branching, with NO re-commit back to upstream, despite NOT support svn:{externals,ignores}, mmy bzr-svn branch/co *of* (from?) the central svn repo will be locally complete, with all the externals, etc pulled in. correct? [00:09] AND, I can hack to my heart's delight, then 'bzr merge' to repull upstream changes later? [00:11] lifeless: it seemed more symmetric to me to clone on both transports [00:11] bendj, well bzr treats imported svn revisions as regular bzr commits. So yes you can do anything with your branch. As long as you do not rewrite history you will be able to merge from svn. [00:11] mwhudson: if I was writing it I would use relpath and the transport itself, I think. [00:11] if the control dir was called something other than .bzr i should be doing something else, like comparing .transport and .root_transport [00:12] bendj, so commit .bzrignore and use join to get the externals. And got wild =) [00:12] bendj, just don't use rewrite plugin and don't uncommit svn revisions [00:12] mwhudson: perhaps a :XXX that it won't handle non .bzr control dirs [contrasting with cloning or a complete copy] [00:12] and don't merge partial revisions e.g. merge -r-20..-19 [00:13] mwhudson: and use the code you wrote [00:13] lifeless: i can agree to that, certainly [00:14] xnox i clearly misunderstood the need -- some, anyway -- for maintaing the externals/ignores for one-way-only checkout/branch. still, the need's fully there for re-commit. just ping-ed the "power that be" for input. pending ... [00:14] xnox: does your 'method', by any chance, exist anywhere in print? on the wiki, perhaps? [00:15] bendj, well I can blog it now to planet =) [00:16] mwhudson: I don't suggest these things just to make your life hard :P [00:16] mwhudson: its a corollary to not using the standard bzr glue to do things [00:16] indeed [00:16] xnox: Would be useful if 'immortalized' ... btw, WHICH Planet? [00:16] Ubuntu Planet =) [00:16] doing the right (well, more right) thing doesn't seem to hard actually [00:17] xnox: thx. (rss to the rescue ...) [00:17] lifeless: is this the sort of thing you meant? http://pastebin.ubuntu.com/424287/ [00:18] mwhudson: that would make me maximally happy, if you're able to use it [00:18] mwhudson: you can make it a little more compact if you like: (sec, typing) [00:19] lifeless: it passes my tests, so yeah i'm happy to use that [00:20] http://pastebin.ubuntu.com/424288/ [00:20] mwhudson: the mkdir and ensure_base were redundant, so I folded together [00:23] lifeless: well, not quite, because ensure_base will only create '.' [00:24] but a create_prefix is cleaner anyway [00:24] mwhudson: oh, doh :) [01:19] bendj, published [01:19] bendj, http://tinyurl.com/bzr-join [01:39] xnox: Thanks -- just caught it on the feed :-) [01:39] bendj, does it look ok ? [01:40] i mean formatting [01:41] xnox: yup. formatted nicely on this end [01:43] brb ... [02:39] ping xnox [02:39] bendj, pong [02:40] xnox: just fyi, http://github.com/andrep/git-svn-clone-externals. adaptable, perhaps .. [02:41] yeah i guess but =) [02:41] aha, the 'yahbut' ... [03:03] what's the point =) [03:03] i like my way cause I know I'm on single branch, i can share it with people and work together [03:03] and my joined branch doesn't require any other commands / plugins [03:06] xnox Sure. Different strokes ... adminttedly, I'm looking at a scripted solution for projects with large #'s of svn:externals ... [03:06] agh! admittedly [03:07] bendj, I know a tool like that =) [03:07] it starts with "s" and ends with "n" [03:08] comment += $comment . ' ... and that pulls it all into a local DVCS.' [03:26] =) [03:40] This page (http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/svn_plugin.html) references "rich-root", as in: 'bzr init-repo --default-rich-root'. manpage fails to mention "--default-rich-root" as a specific option, and states for "--default" that "Provides rich roots which are a one-way transition.". [03:40] And, of course, search in docs (http://doc.bazaar.canonical.com/bzr.dev/en/search.html) on 'rich-root' comes back empty. [03:40] W. T. F. ?! [03:40] where is this documented? Buehler? Buehler? [03:41] I think the docs are a bit out of sync [03:41] the new default format in bzr 2.0 is the 2a format, which is a "rich root" format [03:41] so there's no (longer) --default-rich-root, because --default is already rich root [03:42] I'd say svn_plugin.html should be changed, I'd suggest filing a bug report [03:44] idnar: Ugh. Ok, b4 I do, I'm gonna try to 'sed' the commentary at https://answers.launchpad.net/bzr/+question/71563#6 "... The reason appears to be that bzr doesn't set a unique root ID for a branch unless it was *created* as a rich-root branch. ...", to see if it stil holds. [03:44] idnar: Thanks. I think. [03:45] Although, I think I've bumped squarely into the lack of nested-tree support. again. But by another path ... [05:06] spiv: (moving from #launchpad) I guess that would help, but I wouldn't want to define a prefix for each and every one of my projects [05:07] I can't find the plugin I was thinking of, but bzr-bookmarks is perhaps close enough. [05:07] maybe what I really need is a browser plugin so I can click a button when I'm viewing a merge proposal, and have it grab the corresponding branch [05:08] that's not the only time I branch a new remote branch, but it's probably the most common [05:08] * idnar looks at bzr-bookmarks [05:09] I *think* actually that bzr-bookmarks will look at locations.conf, but perhaps only if you already have a branch. Hmm. [05:09] idnar: make something that hooks into the scheme provider [05:09] idnar: so if you click on lp:some-branch it fires up an app to get it :) [07:27] <_habnabit> If I did a bzr checkout by accident instead of a bzr branch from a launchpad branch, is there an easy way to switch? [07:27] <_habnabit> I have uncommitted changes that I don't want to implicitly push. [07:27] _habnabit: bzr reconfigure --standalone [07:27] Oh, oops, wrong option [07:28] <_habnabit> --branch ? [07:28] bzr reconfigure --tree [07:28] <_habnabit> Aha. [07:28] <_habnabit> Thanks! [07:28] (Or 'bzr unbind') [07:28] <_habnabit> That did it. [07:28] <_habnabit> Oh nice, that looks like exactly what I want. [07:50] hi all ! [07:52] spiv: Can we talk briefly about https://code.edge.launchpad.net/~vila/bzr/401599-strict-warnings/+merge/23932 ? [07:54] spiv: I've got the feeling you're searching for a test modification that has been done in a previous submission where the behaviour changed, this one was about the displayed message which was misleading [07:54] vila: well, I've checked what trunk without that does, and what that patch changes. [07:54] spiv: we were still saying 'use --no-strict to force the push' even if the push was already occurring [07:55] vila: what other submissions should I know about? I didn't notice any mention of them in that proposal. [07:55] spiv: did you see a behaviour change ? [07:56] I did, and I agree with it. But I don't see a test for the behaviour change. [07:56] (To be precise: a behaviour change in your proposal relative to what was in trunk) [07:56] huh ? Which one ? [07:57] Er, the bits of the patch that touch files other than NEWS and bzrlib/tests/* [07:57] spiv: the previous submission is revno 5151 in trunk [07:58] i.e. the behaviour change described in the NEWS entry. [07:58] I'm rather confused. [07:58] spiv: well, the other files only modified the displayed message, not if we push or not [07:59] The display of a message *is* behaviour. [07:59] haaa, that's were we were misundestanding each other :) === knitt1 is now known as knittl [08:00] ok, I made a distinction between whether we were pushing or not (or dpushing or sending) and what message we displayed [08:00] before the last submission the tests weren't checking the message, I changed that and that only [08:01] But the tests still don't test that no warning is displayed in cases where we expect no warning: i.e. tests that would have caught the original spurious warnings. [08:01] spiv: they do now [08:01] No, they test something much weaker. [08:02] more focused, not weaker [08:02] for example: push displays 'Created new branch' [08:02] On stderr? [08:03] if we change it to 'Created new branch up to revno nn' the test doesn't have to be impacted because we already check that we push the right revision [08:03] yes on stderr [08:03] I mentioned that in my previous answer (but you didn't cite this part) [08:03] Not deliberately, I just missed that bit :) [08:03] no worries [08:04] the truth is, after your review, I tried to build the full stderr content and this was... dirty [08:05] As I said I'm not a big fan of assertContainsRe since it weakens some tests, but here.... I found the balance was in favour of it [08:05] So, the test for "doesn't contain this regex" is weak, in the sense of being fragile. [08:06] kind of, [08:06] (Even though it is focused on the specific messages we care about) [08:06] it's also robust about spurious changes in the part it didn't care [08:06] Because it will easily pass incorrectly with minor wording changes. [08:07] So the risk of incorrect failures is low, but the risk of incorrect successes is high. [08:07] If the changes are in unrelated messages, the test shouldn't have to care [08:07] hi vila [08:07] It would be nice if run_bzr could give us a list of warnings emitted to the user, or even just a list of messages. [08:07] hey poolie ! [08:08] spiv, that would be nice [08:08] Rather than a single lump of bytes that got written to stderr. [08:08] spiv: pfew, yeah [08:08] there is code to capture them, of course [08:08] but not on by default there [08:08] more standardization needed [08:08] But, we may be able to cheat that by splitting stderr by lines? [08:08] poolie: that needs to be factored out for trace.warning :-) I think I know about at least 3 or 4 call sites now [08:08] Because in many cases there's a one-to-one correspondence between a line and a message/warning. [08:09] vila, how about a brief call? [08:10] vila: So, I feel these tests of cmd_push ought to be able to account for every line of output [08:10] spiv: my position is that, on principle I agree with you about the strict checking of stderr, but in this specific case I made an exception because: 1) I see little to be gained, 2) the resulting code was awful (I revert to the simpler version I landed when I saw that) [08:11] poolie: just a sec [08:11] vila: perhaps pass a regex list to add to a default list that expects to see the "N new revisions" or whatever. [08:11] (using "line" as proxy for "message or warning", which perhaps is overly optimistic) [08:12] spiv: yeah I thought about that too, but it's all the same in the end, if we check regexps there will still be holes and adding unrelated messages there is just asking for trouble: when they change the tests will fail for the wrong reason [08:12] I agree the benefit for cmd_push is low, but ideally we'd find a way to do this that we can reuse in other places. [08:13] Capturing the warnings emitted more directly might be better than asserting about the exact bytes on stderr, I can see arguments either way. [08:13] (It's kind of a shame we only get 2 channels to emit messages on!) [08:13] and to be honest, using blackbox tests there feels wrong, but it's often the case when trying to observe the behavior of command lines options that are handled in command.run() [08:14] But, if there's one thing I'd like you to take away from this review: [08:14] test should fail first ? :) [08:14] It's don't claim that what is shown in the UI is not behaviour ;) [08:15] hmm [08:15] heya bzr! [08:15] _o/ vila [08:15] spiv: I'll think about it [08:15] hey bialix [08:15] poolie: calling [08:16] hi bialix [08:16] vila: I can argue about in some detail, but perhaps the main justification for me saying that is "it'll confuse people" :) [08:16] hi poolie :-) [08:16] spiv: I agree, it's just my poor english [08:16] vila: and that english is poor! [08:17] vila: http://ostatic.com/blog/more-bad-english-please [08:17] I've fwd this article to ru_bzr people and suggest to not shy filing more bug reports [08:18] * bialix is working as english proxy sometimes [08:18] spiv: small request - start setting commit messages (e.g. on [08:18] https://code.edge.launchpad.net/~gagern/bzr/bug387117/+merge/23750) [08:20] lifeless: it's a bit grating at the moment that feed-pqm-by-email and feed-pqm-by-lp-queue-magic expect different formats for the commit messages, AIUI. [08:21] :) [08:21] er, wrong window [08:21] So that discourages me from setting it unless I'm about to submit it myself. [08:23] Thinking of which, if PQM is reading directly from LP, perhaps it should just set the author revprop rather than putting it in the commit message. [08:23] spiv: feed by lp queue seems very reliable to me know, I've been tracking it this week and no exceptions in th elogs according to spm [08:23] s/know/now/ [08:23] spiv: I don't think setting author is appropriate [08:24] pqm is merging, the history knowledge of who introduced lines is in the history [08:24] Then why are we putting the name in the commit message? [08:25] spiv: I'm not sure. I know why we put the queuer there, but the author never really made sense to me. [08:25] I thought it was because we wanted to credit the author for people viewing the mainline, but PQM didn't give us control of any fields other than the message. [08:25] I got asked to do it/followed what Martin was doing or whatever some years ago [08:26] spiv: pqm has always been modifiable [08:26] spiv: I object to mangling metadata incorrectly to solve reporting problems; we should just report better. [08:27] Sure, but lack of tuits involved in improving PQM, getting it deployed, tested, and upgrading the pqm-submit plugin devs were using to use it meant that never happened because the workaround was bearable. [08:27] spiv: I'd be happy to drop the trailing (author) [08:28] if we were to set author in pqm, it should be to the queuer, IMO. [08:28] because they are conceptually responsible for the merge [08:29] I don't see that "author" is an incorrect name for the field. Yes it might not be the sole work of that person, but the person responsible for proposing the patch is assumed to be the person responsible for assembling it and otherwise doing some significant work towards making it land. [08:29] I've a little trouble binding things there [08:29] I'm not particularly against thinking of a better field, I just don't know that the distinction is more important. [08:29] could you rephrase [08:31] The primary person we typically credit in commit messages is generally the person that proposed the patch. The person that proposed a patch is generally the person that wrote most of it, or at least did significant work on it (e.g. backporting). Calling people that do that "author" seems good enough for me. [08:31] Especially if it unclutters the commit logs :) [08:31] do you mean the person in the trailing () or the leading () ? [08:33] spiv: perhaps we can talk more next week on this [08:33] spiv: I'm really convinced we should be able to show the people without setting author on a merge daemon [08:33] Well, we aren't completely consistent about how we use trailing/leading (), so the answer seems to be "trailing, or leading if trailing is absent, or 'for $name' in leading if given" [08:34] Yes, showing the people is the main thing. The second thing is not abusing commit messages. [08:34] Author is a convenient hammer for achieving those two, but I'm not wedded to it. [08:35] I don't like setting author for a few reasons; we don't do it when we do merges by hand in other projects; it doesn't map well IMO to the intent; it will generally tag precisely zero lines. [08:36] What do you mean by tagging lines? [08:36] in annotate [08:36] you see the revisions that introduce text to the tree [08:36] the annotation view of bzr shouldn't [in general] attribute *any* lines to pqm [08:36] Sure. I'm not too bothered by annotate. [08:37] the most grating thing to me, I think, is that the old default log avoids the question entirely; it shows *the right stuff*, and there aren't any questions about the contributors to a patch. [08:37] I'd be happy to see lp-proposed-by and lp-landed-by revprops. [08:38] spiv: proposed/landed/queued ? [08:38] hi lifeless [08:38] hi poolie [08:38] lifeless: sure, whatever names, just capturing the data in a sane way :) [08:38] spiv: ack [08:39] But there's more than just log (old or new): there's qlog, there's loggerhead, there's the branch page on LP... [08:40] And none of them, today, report the authors/committers of non-mainline revisions in their default view. [08:40] yeah [08:40] this saddens me [08:40] Me too. And AfC for that matter :) [08:41] The existence of PQM as the committer on mainline is far from the most interesting fact about that revision. [08:42] *Any* of the people involved would be better, in many ways. [08:42] queuer is IMO signed-off-by in git [08:43] Right. [08:46] Ooh, there *is* a way to see Queued proposals for a branch: https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges?field.status=QUEUED (empty atm) [08:47] whats maximise-window-vertically in vim, again ? [08:48] Ctrl-W _ [08:49] thanks === radoe_ is now known as radoe [08:58] Apparently there's a "Code failed to merge" state. [08:58] yes [08:58] can't be used [08:58] Heh. [08:58] see my branch, nag thumper to reply to my review [08:59] spiv: indeed [09:00] * AfC is abashed that spiv remembers him. Aw shucks. [09:31] poolie: about https://code.edge.launchpad.net/~jbowtie/bzr/fix-555439/+merge/24289 is the contributor agreement in the pipe ? [09:33] spiv: Can we mark https://code.edge.launchpad.net/~spiv/bzr/push-relock/+merge/23767 as wip ? [09:33] lifeless: I'll talk to you about it tomorrow, there are things I want to discuss [09:37] thumper: naturally [09:37] thumper: needs to be early, I have a plane flight at 1:30, leaving 10:45 or so [09:37] ok [09:37] lifeless: ping me in the morning [10:00] vila: https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 was originally created on the 3rd of March [10:00] therefore is nearly 2 months old [10:00] the overview page only shows the date a review was most recently requested [10:01] and i see you have been following up on that and need win32 help [10:01] (bialix :-) [10:04] for those wondering, i'm not nagging vila, i'm just answering why the "oldest mp" graph says 2 months when there don't immediately seem to be any so old [10:14] vila: hmm, I suppose. Although I don't know if the next step should be "make read-locks upgradable into write-locks" or just "land this hack" [10:18] I'm ni favour of the former, quite strongly. [10:18] I think its only slightly more work. [10:26] poolie: thanks [10:27] spiv: at your leisure, I'm just trying to clean up the review queue [10:46] I just added my work pc's SSH key to LP, did a launchpad-login but my commit didn't come through 'linked' to my username? [10:49] sproaty: the commit linkage is based on the name+email you've set with "bzr whoami" [10:49] (Or the name+email bzr has guessed if you haven't explicitly set it; either way, "bzr whoami" will show you what name is being recorded in your commits) [10:50] ah ok I just changed those (after commiting :p) [10:50] There's a bug + patch for making bzr never guess the 'whoami', btw. Sounds like that would have helped you :/ [10:52] thanks [10:58] ahh I changed whoami now I get this when pushing bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~sproaty/whyteboard/development/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [10:58] https://answers.launchpad.net/bzr/+question/24695 doing lauchpad-login and bzr bind as suggested here, problem still exists [11:02] sproaty: what command are you trying? "bzr push lp:~sproaty/whyteboard/development"? [11:03] sproaty: it's trying http rather than bzr+ssh, which suggests that either you aren't using the lp: URL, or somehow the "bzr launchpad-login" hasn't taken effect. [11:03] that's what I pushed to earlier (with wrong whoami) - now I'm just doing push [11:03] ah there we go [11:04] specifying the url directly again worked [11:04] Ok, it's probably remembered the http one. If you do "bzr push --remember lp:~sproaty/whyteboard/development" that should solve that. [11:04] are these now right? http://paste.pocoo.org/show/207461/ [11:05] cool cool [11:16] No, none of the branches on launchpad should start with http:// if you have done launchpad-login === AfC1 is now known as AfC === mrevell is now known as mrevell-lunch [13:04] what's the purpose of commit object passed to generate_commit_message_template function? [13:04] is there any real-life examples of commit_message_template hook? [13:06] jelmer: I found your patch of commit_message_template hook: http://markmail.org/thread/etkxlj6osy65rhfb . can you point me on any existing hooks? [13:09] bialix: bzr-builddeb has one I believe [13:09] bialix: it fills in the commit message based on the contents of debian/changelog [13:09] that's what I need [13:10] commit object should have link to working tree, right? [13:10] yeah, I think so [13:11] commit.work_tree [13:11] oki [13:16] jelmer: do you know why commit_message_template hook gets the commit object as argument? why not passing just working tree there? [13:18] jelmer: actually you're the author of that hook [13:18] qann say so [13:19] It's a more flexible interface. [13:20] It allows us to add more attributes to the commit object without breaking existing hooks. [13:20] spiv: for example? [13:20] bialix: specified_files [13:21] If we passed arguments like working tree directly then to add another argument then it would break the hook. [13:22] but that hook launched only with work_tree argument attached to commit object!!! [13:22] jelmer: I don't see where specific_files attached to commit_object [13:22] bialix: it's not yet attached, but it would be a good candidate [13:22] bialix: and we'd like to be able to make that sort of change without breaking existing hooks [13:23] so it can't really be an argument to the hook [13:23] :-/ [13:23] Generally new hooks have dedicated "params" objects [13:23] guys, I need the way to run these hooks without calling wt.commit so I can use them in qbzr [13:23] today it seems impossible hard [13:24] because hooks called from commit object [13:24] and I need valid commit object to fire hooks [13:24] it's a kinds of recursion, it's not? [13:25] commit_message_template is a hook for controlling the message template to use for a commit.' [13:25] when you start to talk about flexible I'm starting to fear [13:25] So by definition it needs a commit object [13:25] Why can't you create one? [13:25] I can create one, but I should attach all required attributes there manually [13:26] because they're attached only when actual commit started [13:26] so far I see there is only work_tree and branch attributes attached, then hook fired [13:26] now you say there is need for specific_files [13:26] it's a kinda open can of worms [13:26] * bialix don't like open ended [13:27] bialix: specific_files isn't there yet but it might be added in the future [13:27] I'm not sure why qbzr can't call wt.commit? [13:27] Perhaps look at how cmd_commit does this. [13:27] spiv: because we allows user to enter message *before* we call commit [13:28] it's a gui application [13:28] The hook is invoked by generate_commit_message_template, which is invoked by the get_message callback that cmd_commit passes to tree.commit [13:28] yes, exactly [13:28] Why not allow the user to enter the message during commit, like the CLI? [13:28] and tree.commit is the real commit [13:29] spiv: http://groups.google.com/group/qbzr/t/f266b47d77e4bacb [13:29] The issue is that the real commit can affect what goes in the template. [13:30] why? [13:30] or more precisely: how? [13:30] Because the template often includes a summary of affected files, etc. [13:30] I see this hook as CLI-only thing [13:30] I don't see that way. [13:30] spiv: in qcommit user can select/deselect files interactively [13:31] so the summary will be known only when commit started [13:31] I need template *before* [13:31] heh [13:31] Ok, then you can't use the hook that generates templates based on that information. [13:33] Perhaps we could add a hook that works from a more limited set of information, although it would be correspondingly less useful... [13:33] I can live with that [13:34] But that post you just linked to suggests that you do want your templates to know if changelog/news is going to be part of this commit. [13:34] So it sounds to me like you have contradictory requirements. [13:34] spiv: currently that hook don';t have such info [13:35] spiv: I don't care if user will deselct the changelog file -- because user can just select suggested templated and delete it as well [13:35] it's a GUI [13:35] Actually, glancing at the code, specific_files does seem to be defined at the point the message_callback is invoked. [13:35] *exactly* [13:36] bialix: ah, now that suggests a solution to me: [13:37] bialix: start a real commit to get the message template then abort it. [13:37] ? [13:37] sounds crazy [13:38] Well, AFAICT that actually matches exactly the behaviour you want: [13:39] spiv: I think I don't want to start commit until user presses OK [13:39] You want to the initial message (that the user can edit) to be what the hook suggests if the user just committed everything. [13:39] yes [13:39] that's my point [13:39] So, construct that commit, use it to get the template, then abort it and throw it away. [13:40] Then once the user has edited the message and files etc, and clicked ok, do a commit (and let it finish). [13:40] how I can abort commit? [13:40] By raising an exception from the message_callback. [13:41] * bialix scratches a head [13:41] It's a bit of a hack (and will quietly log a traceback), but will work. [13:41] yep, it looks like a hack [13:41] thanks for the suggestion, but I don't like this idea [13:42] We can add some sort of cleaner API (perhaps just an explicit AbortCommit exception) if this is useful for you. [13:42] Just because the way to abort the commit is a hack? [13:42] I don't know yet [13:42] Fair enough :) [13:42] I don't know yet if I need AbortCommit [13:43] I don't like idea of aborting commit because it's a waste [13:43] That's true. [13:44] The only other option is providing a way for a GUI to interactively configure the Commit object between starting and finishing it. [13:44] And I think that would either be a lot more complex for bzrlib, or actually work out to be essentially the same as "throw the first one away and restart it". [13:44] yes, but for this I need to understand the required API of the hook, and it's not defined yet [13:45] Because you are fundamentally asking for repeated work. [13:45] no, when qcommit will start the real commit there will be passed real commit message and the hooks won't fired [13:45] The commit message template by definition depends on what is being committed. [13:46] And you want that template before finalising what is committed. [13:46] I'm reading the http://bazaar.launchpad.net/%7Ebzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py#L85 [13:46] and I see that in the end there's a lot of manual work [13:46] no real benefit from commit object [13:47] or maybe I'm blind [13:47] Oh, to be fancy you don't *have* to abort the first commit if the user doesn't deselect any files or change anything other than the message... [13:47] spiv: actually we run plain `bzr commit` under the hood [13:47] that's why I don't want to manually invoke wt.commit [13:48] maybe I can think about using MemoryTree instead, but anyway it's a waste [13:48] Well, if you want to integrate very closely, at some point you need to use bzrlib directly. [13:48] bialix: perhaps you can propose an interface for the object that's pased to the commit_message_template_hook ? [13:48] no, I'm only want to have template [13:48] it was to spiv [13:48] bialix: that interface could then be implemented by Commit as well as some qbzr-specific object [13:49] bialix: I agree that hook's params don't provide as many convenience methods as it could or should [13:49] jelmer: ok, I'll think about this [13:49] bialix: I've recently don't some work on the merge_file_contents hook to add that sort of convenience. [13:49] but it's real and used now, so anywy there is should be a way for backward compatibility [13:49] (although there's a long way to go) === mrevell-lunch is now known as mrevell [14:50] Hrm.. bzr ci is now failing for me, because it can't talk to gnome keyring, apparently. I don't even run gnome.. [14:50] ** Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files [14:51] LeoNerd: does bzr-gtk appears in the output of 'bzr plugins -v' ? [14:52] Yup [14:52] LeoNerd: if you don't run gnome... don't install it :-) [14:52] LeoNerd: yet, it's a bug, can you file it ? [14:52] gtk != gnome [14:53] gtk provides nice shiney visual stuff. [14:53] I don't know if it's a bug... [14:53] ha, that kind of user :) [14:53] it is a bug you can't use bzr ci with bzr-gtk installed [14:53] s//that/ [14:53]