[00:08] <stewart> lifeless, is there any way to trace what bzr is reading from remote? basically i want to strace the stuff read from bzr+ssh
[00:08] <lifeless> -Dtransport
[00:08] <thumper> lifeless: does bzr handle utf-16 files?
[00:08] <lifeless> if you are lucky :)
[00:08] <lifeless> there is also log+lp:...
[00:08] <lifeless> and trace+ I think - see bzrlib.transport/*
[00:08] <lifeless> thumper: in what way
[00:08] <stewart> lifeless, trying to trace what sync-pipeline is doing.
[00:09] <thumper> lifeless: in storing them, diffing, normal stuff
[00:09] <thumper> lifeless: so you can diff two utf-16 files
[00:09] <thumper> at least that is what I think they were asking
[00:10] <lifeless> uhm
[00:10] <lifeless> broadly yes, but we can do better than we do
[00:10] <lifeless> they may, at the moment, be detected as binary files some of the time.
[00:11] <lifeless> our storage treats binaries and texts the same way, so no change to efficiency there
[00:11] <thumper> hmm..
[00:11] <thumper> lifeless: I'm writing up the result of my talk
[00:11] <lifeless> however if they detect as binary, diff will just say 'binary changed'
[00:11] <thumper> lifeless: on the whole it went well
[00:11] <thumper> yeah, that is binary check is a big hammer
[00:12] <thumper> utf-16 files have a specific header block don't they?
[00:12] <lifeless> the BOM
[00:12] <lifeless> sometimes
[00:12] <thumper> oh?
[00:12] <thumper> not all the time?
[00:12] <lifeless> right
[00:12] <thumper> BOM?
[00:12] <lifeless> utf16 is an encoding
[00:13] <lifeless> BOM (the byte order mark) is something you can put in any utf* document to let content sniffers figure the encoding out
[00:13] <lifeless> you can have a BOM on utf8
[00:13] <thumper> kk
[00:14] <lifeless> http://en.wikipedia.org/wiki/Byte_order_mark
[00:16] <lifeless> lol
[00:16] <mathrick> it's almost always a bad idea though
[00:16] <lifeless> 'The only solution is to hunt down the affected PHP file(s) and manually remove the BOM characters with another editor.'
[00:16] <lifeless> I want to edit it and add 'or fix php'
[00:16] <lifeless> mathrick: oh, I know.
[00:16] <mathrick> lifeless: seriously, it's Win32 being idiotic here
[00:16] <lifeless> mathrick: I know
[00:16] <mathrick> BOM for UTF-8 is a dumb, dumb, dumb idea
[00:17] <lifeless> the order is guaranteed in the encoding, its not needed. *I know*.
[00:17] <stewart> lifeless, didn't do anything. trying every other -D option on the help page.
[00:18] <lifeless> stewart: add trace+ to the start of your url
[00:19] <lifeless> actually not
[00:19] <lifeless> add log+
[00:20] <stewart> lifeless, could bzr+ssh be having some sort of caching launchpad side?
[00:20] <lifeless> no
[00:20] <stewart> lifeless, where does the log go? or do i also need -D ?
[00:20] <lifeless> ~/.bzr.log
[00:23] <stewart> it seems much slower at least...
[00:24] <stewart> i wonder if there's cache hiding or something.... eep.
[00:28] <stewart> what. the. fsck...
[00:28] <stewart> lifeless, it seems to be working now that i've specified log+ on the command line.
[00:29] <stewart> abentley, ^
[00:48] <thumper> igc: screenshots/windows/menu-Start.png seems to be missing on http://doc.bazaar.canonical.com/explorer/en/visual-tour-windows.html
[00:49] <igc> thanks thumper: I'll take a look
[00:53] <thumper> igc: I also sent an email about the talk to the internal list
[00:57] <igc> thumper: so the file was called menu-start.png accidentally. Fix committed now. Should refresh on the website soon.
[00:57] <thumper> igc: cool
[01:28]  * igc lunch
[01:38] <stewart> lifeless, abentley: after that magic (run with log+ and then it works better), then having to fix up branch.conf on an *old* pipe... things seem to be working again.
[01:53] <lifeless> stewart: no idea why log+ would influence it
[01:53] <lifeless> stewart: its a passthrough decorator
[01:53] <stewart> lifeless, *weird*
[02:38] <GungaDin> is it possible to turn a checkout into a branch?
[02:40] <fullermd> Yes, you can use 'reconfigure' for that.
[02:54] <parthm> hello, i am looking at bzr-grep bug #539258. any unicode experts here?
[02:55] <parthm> the fix i had in mind was to simply "line = line.decode('utf-8', 'ignore')" before printing.
[02:55] <parthm> is that reasonable?
[02:58] <thumper> is there a bzrlib module for dealing with paths and filenames?
[02:58] <thumper> like a special os.path thing?
[02:58] <thumper> like getting the basename of a full path
[02:59] <thumper> and such
[02:59] <thumper> parthm: we do something similar in launchpad, let me look
[02:59] <james_w> thumper: there's osutils
[02:59] <james_w> and urlutils IIRC
[03:01] <thumper> parthm:         try:
[03:01] <thumper>             diff = preview_diff.text.decode('utf-8')
[03:01] <thumper>         except UnicodeDecodeError:
[03:01] <thumper>             diff = preview_diff.text.decode('windows-1252', 'replace')
[03:01] <thumper> that seems to catch most issues
[03:01] <thumper> james_w: thansk
[03:01] <thumper> james_w: in bzrlib?
[03:01] <james_w> IIRC
[03:02] <james_w> yeah
[03:02] <parthm> thump: thanks. so windows-1252 is used by windows?
[03:02] <james_w> thumper: bzrlib.urlutils.basename seems like it might be what you want
[03:02] <thumper> james_w: yeah, just looking at the pydoctor docs
[03:02] <thumper> james_w: thanks
[03:03] <thumper> parthm: yes, it is one of the standard windows encodings
[03:03] <thumper> parthm: it is similar to the extended latin-1
[03:03] <thumper> parthm: but with a few differences
[03:04] <james_w> thumper: do you know if there is a request in the works to get more hardware for vcs-imports?
[03:05] <parthm> thumper: thanks. that seems to be working fine. what does 'replace' do as compared to 'ignore'. the help(x.decode) isn't very clear.
[03:05] <thumper> parthm: I don't remember
[03:06] <thumper> sorry
[03:06] <parthm> thumper: no problem. thanks for your help :-)
[03:10] <parthm> got it. 'ignore' lets the bad chars be, 'replace' replaces them with '?'
[03:11] <thumper> parthm: handy to remember
[03:16] <lifeless> james_w: its early for you, isn't it ?
[03:18] <james_w> lifeless: late, I'm out of timezone once more
[03:18] <lifeless> ah
[03:19] <lifeless> well when you're in $worktime, can you please mail me the stuff remaining for the watch-ppa bzr-builder branch to land
[03:19] <lifeless> we're moving to UEC and I really need to be able to just install a package at this point, so I'll do whatever you want
[03:22] <Peng> str.decode('replace') replaces them with the Unicode "I dunno WTF that was" character. unicode.encode('replace') replaces characters that the encoding doesn't support with '?' (or perhaps something else if that isn't supported?).
[03:24] <parthm> Peng: yes. i am seeing the unicodes little white on black '?' as I am using str.decode :-)
[03:25] <Peng> U+FFFD, to be specific,.
[03:40] <james_w> I've just done annotate to get the revno of a change that I am interested in
[03:41] <james_w> how do I get the log of all the revisions that were done between that branch diverging from LH ancestry and being merged back in there?
[03:41] <james_w> the change I am actually interested in was done on that branch, but not in the indicated revision
[03:41] <lifeless> do a log -r --show-ids to get the rh parent
[03:42] <lifeless> uhm, and we don't have a good pithy-graph-operator, sorry.
[03:42] <lifeless> bzr viz :
[03:42] <james_w> how do I find that revision in bzr viz?
[03:46]  * james_w does it the silly brute force way
[03:47] <lifeless>  /revid
[03:56] <lifeless> time for some wotw
[05:25] <fullermd> Furrfu, SF is still on 1.10.
[05:29] <lifeless> ,ee[
[05:29] <lifeless> sorry
[05:29] <lifeless> meep
[05:30] <fullermd> Hm.  Or maybe not.  The shell service actually has 2.0.3.  The site still claims 1.10 though.
[05:31] <lifeless> perhaps a 'min version'
[05:33] <fullermd> 'd be nice if they at least said explicitly somewhere.  Then I'd know if I should bother trying to convert and upload a 2a branch of a project I don't have time to work on anyway...
[05:34] <GungaDin> shouldn't commit push the history to the original repository I checked out?
[05:36] <fullermd> Commit puts a new revision on the branch you're working on.  So it depends on what branch you're working on.
[05:36] <GungaDin> it's a checkout.
[05:36] <fullermd> If you ran a command like "bzr branch some/where here", your branch is 'here'.  If you ran something like 'bzr checkout some/where here', your branch is 'some/where'
[05:37] <GungaDin> I have a checkout of a branch in linux
[05:37] <GungaDin> and a checkout of the linux  checkout on windows
[05:37] <GungaDin> I commited on windows and can't see the new commit on linux
[05:37] <fullermd> Making a checkout of a checkout is unlikely to work well.
[05:38] <fullermd> Regardless, check 'bzr info' to be sure you actually have what you think you have.
[05:39] <GungaDin> yeah, like I described
[05:39] <GungaDin> I committed on the checkout of a checkout
[05:39] <GungaDin> and can't see it on linux
[05:40] <fullermd> I have dark suspicions that checkouts of checkouts invoke nasal demons.
[05:40] <GungaDin> so what should I do? try to push to the original branch?
[05:40] <fullermd> But still, I suspect at least that first hop may work right.  How are you expecting to see it?
[05:41] <GungaDin> in bzr log
[05:46] <fullermd> Well, I can make all sorts of strange, bizarre, and unhygenic things happen with some local fiddling with co's of co's.
[05:46] <fullermd> But after a commit at the tail of the chain, the next step up has the rev, at least until I 'update' it.
[05:48] <fullermd> Somewhat annoyingly, all local links properly prohibit commiting in a co of a co, but across a network protocol it doesn't.
[07:25] <vila> hi all !
[07:26] <Peng> Good morning!
[07:34] <jelmer_> moin vila
[07:34]  * vila waves@jelmer (my god, already up ? Not at home ? :-P)
[07:35] <jelmer> vila: Yeah, I'm in London :-)
[07:35] <vila> jelmer: hehe, I spent the week-end there, that was nice :)
[07:56] <thumper> why is workingtree.commit undocumented?
[07:56] <thumper> not helpful
[07:59]  * thumper reads the source
[08:11] <tasslehoff> We use svn, and need to pull down an external git repo for our project. I don't think svn allows me to have a git repo as an external. Is this something bazaar can help me with?
[08:13] <lifeless> thumper: its MutableTree.commit
[08:13] <lifeless> thumper: and the guts are in bzrlib.commit
[08:13] <thumper> lifeless: that isn't documented either
[08:13] <thumper> lifeless: the source told me enough
[08:13] <lifeless> thumper: the older the code is the less well documented. commit was _very_early
[08:13] <thumper> lifeless: heh
[08:34]  * igc dinner
[10:03] <lifeless> thumper: hows the hacking
[11:13] <persia> Good day.  I'm curious how well/badly bzr branches would deal with being hosted in ubuntu one.
[11:13] <persia> I heard somewhere that bzr tracks inodes, which might break because of how ubuntuone copies files.
[11:15] <lifeless> bzr has an inode concept of its own
[11:15] <lifeless> it doesn't track fs inodes
[11:16] <lifeless> however, given ubuntu one doesn't act like a posix file system, theres every chance of weird shit happening.
[11:16] <persia> Ah, so if one just randomly copies a bzr branch, it ought still work?
[11:16] <lifeless> I wouldn't do it.
[11:16] <lifeless> oh yes
[11:16] <persia> OK.  Why wouldn't you do it?  rye tells me svn works fine.
[11:16] <lifeless> by doesn't act like a posix file system, I mean that unordered changes made on machine A are applied to machine B
[11:17] <lifeless> an svn *repository* or an svn *checkout* - totally different things.
[11:18] <lifeless> a bzr lightweight checkout (which is approx a svn checkout) would work fine, and only be buggered if you ran 'status' on two different machines, for instance.
[11:18] <lifeless> persia: the problem is that if bzr writes to a file - any file; u1 tries to replicate that.
[11:18] <persia> Seems it was just a checkout.
[11:18] <lifeless> persia: but bzr is treating the fs as a place to do locking, and store a database.
[11:19] <lifeless> would you put postgresql in u1?
[11:19] <persia> That might be my next question :)
[11:19] <persia> So it's a locking semantics thing?
[11:19] <lifeless> thats part of it
[11:19] <lifeless> the basic problem is that u1 writes to bzr's storage area.
[11:20] <lifeless> only bzr or your 'I am restoring now' should ever do that.
[11:20] <lifeless> everything else flows from this
[11:20] <persia> Is this a structural issue or an implementation issue?
[11:20] <lifeless> structural
[11:20] <lifeless> applies to putting any DB or structured data in something like U1
[11:20] <lifeless> postgresql
[11:21] <lifeless> sqlite
[11:21] <lifeless> bzr
[11:21] <lifeless> git
[11:21] <lifeless> svn (repo)
[11:21] <lifeless> hg
[11:21] <lifeless> they [probably] won't be a problem as long as you only ever have one machine signed into u1 at a time.
[11:21] <lifeless> as soon as you have two, and have both active: *boom*
[11:22] <persia> Right, which breaks the use case.
[11:22] <lifeless> unless both the software in question is designed for cluster fs's, and u1 were to expose a cluster fs API
[11:22] <lifeless> neither of which is the case for any of those AFAIK
[11:22] <lifeless> I've seen one user lose a bzr repo to u1 so far
[11:23] <persia> That's a cogent explanation, and an excellent data point.
[11:23] <persia> Thanks a lot.
[11:23] <lifeless> It would be nice if it worked better, but I don't think it can without a lot of effort, and I don't think it reflects *at all* on U1's quality.
[11:24] <lifeless> databases syncing isn't their use case (note that they sync couchdb *totally differently*)
[11:25] <lifeless> gnight
[11:25] <persia> gnight.
[12:05] <sttng359> hello
[12:06] <sttng359> I'm looking for a way to replicate the behavior of svn:externals in bazaar.
[12:07] <sttng359> or some method of easily pulling in changes for a large number of Bazaar projects at once.
[12:39] <dvheumen> sttng359, I think there's a plugin called bzr-externals, I'm not familiar with the project though.
[12:52] <sttng359> I found that project, but I also keep running into references of nested branches, but can't find much documentation on it.
[12:53] <sttng359> If I do a branch into a subdirectory of another branch, does it automatically create a nested branch?
[13:02] <sttng359> The main goal I am trying to achieve is nothing more than allowing users to easily update all checkouts up to date.
[13:04] <beuno> sttng359, no, unfortunetely bzr doesn't support nested trees at the moment
[13:07] <sttng359> was that a feature that was never completed or removed?
[13:10] <parthm> hello. i am trying to optimize revision searching in bzr-grep. it seems "text = tree.get_file_text(..)" is taking most of the time.
[13:10] <parthm> setting that to "text = random_block_of_text" makes the time go from 33s to 8s.
[13:10] <beuno> sttng359, never completed
[13:10] <parthm> is there a faster alternative to get_file_text?
[13:19] <vila> sttng359: did you look at bzr-externals ?
[13:23] <sttng359> vila: yes, I now have that installed and am testing it.
[13:23] <sttng359> seems like it will satisfy my needs.
[13:25] <sttng359> On a separate note, if I branch from a checkout made using bzr-svn, can I safely repoint the branch to the original subversion repository?
[13:26] <sttng359> in other words, do branches retain all the meta-data used by the original checkout bzr-svn does?
[13:31] <kfogel> It kind of worries me that if you go to http://bazaar.canonical.com/en/ and do a search (upper right hand corner search box) for the terms "bzr" and "ssh" together, you get no results.
[13:39] <vila> kfogel: file a bug please, I get no results for 'bzr' alone either :-/
[13:39] <kfogel> vila: whoa
[13:39] <vila> that's so big the bug ought to be obvious...
[13:39] <kfogel> vila: yup
[13:40] <kfogel> vila: btw, do you have any experience setting up bzr+ssh:// access where users have only restricted logins on the server machine?  If you do, and can spare 5 min right now, I'd be grateful.
[13:40] <dvheumen> I think it's a different problem: it seems that the search on the top-right expects a wiki pagename
[13:40] <kfogel> vila: I've been running into some problems setting that up.
[13:41] <kfogel> dvheumen: either way, it's a bug
[13:41] <dvheumen> true
[13:41] <kfogel> dvheumen: whether it's the intended behavior or not :-)
[13:41] <dvheumen> well, it's certainly not expected behavior :P
[13:41] <vila> kfogel: I've done it once, let me dig how
[13:42] <vila> kfogel: right, I've done it in .ssh/authorized_keys by prefixing lines with: command="/bin/false",permitopen="localhost:nnnn"  to allow tunneling
[13:43] <kfogel> vila: in authorized_keys?
[13:43] <kfogel> vila: oh
[13:43] <vila> kfogel: yup
[13:43] <kfogel> vila: yes, you said that :-)
[13:43] <kfogel> sorry
[13:44] <vila> np
[13:44] <kfogel> vila: interesting -- this is somewhat different from the advice lifeless gave, but I think he was speaking off the top of his head.
[13:44] <kfogel> vila:  the behavior I'm seeing is that if I create a user 'kffsshtest', and give him /bin/false for shell in /etc/passwd, then when ~kfftest/.ssh/authorized_keys contains this:
[13:45] <kfogel> command="/bin/sh -c 'echo fish'" ssh-rsa [...]
[13:45] <kfogel> it will not echo the string fish when I ssh in.
[13:45] <kfogel> But if I change shell to /bin/sh in /etc/passwd, it does echo fish.
[13:46] <vila> hmm, too many possible explanations here :-/
[13:46] <kfogel> Which strikes me as bizarre -- you'd think it would work to specify an exact command in authorized_keys
[13:46] <kfogel> vila: yeah
[13:46] <kfogel> vila: but I'm thinking: who cares if /etc/passwd lists /bin/sh for people's shells, if the only way they can get in is via ssh, and ssh runs a command?
[13:46] <kfogel> command="/usr/bin/bzr serve --inet --allow-writes"
[13:46] <kfogel> ...will be the actual command, of course
[13:47] <kfogel> plus maybe a --directory option
[13:47] <kfogel> vila: but anyway, that recipe seems different from what you've done, so I'd be curious to see what you've done.
[13:47] <vila> kfogel: it wasn't for bzr use
[13:48] <kfogel> vila: ah
[13:48] <vila> kfogel: where I need bzr I already have shell access but I need to set bzr_remote_ssh in locations.conf
[13:49] <vila> .. for ... various reasons (mostly not using the ystem-wide installed bzr)
[13:49] <kfogel> vila: ok.  This is for a situation where the bazaar committers should *not* have true login access on the server, just bzr access.
[13:49] <vila> then command="/usr/bin/bzr --inet..." sounds fine
[13:51] <vila> kfogel: and you set up as many users as committers right ? (i.e. not a single shared one)
[13:51] <kfogel> vila: that's the idea
[13:52] <vila> then if the server is configured to refuse authentication by password you should be fine, the only way will be by the key and I don't remember an ssh option to work around that
[13:55] <kfogel> vila: so I just filed bug 539587 about the search breakage.  It was a horrific experience -- total Launchpad fail :-(.
[13:55] <kfogel> vila: I went to launchpad.net/bazaar, thinking that was the product name.
[13:55] <kfogel> It somehow decided I meant the Uninstaller for the Bazaar Macintosh Bundle project.
[13:55] <kfogel> By the time I noticed I'd already filed the bug.
[13:56] <kfogel> So I added a new bugtask for project 'bzr' (whose display name is "Bazaar"), and tried to delete the other task.
[13:57] <kfogel> But nooooo, turns out what I was supposed to do was just *change* the task on the old one.  But when I try to do that, entering 'bzr' for the new task fails, and so does 'bazaar': "Too many matches; please try to narrow your search."
[13:57] <kfogel> aaaaargh
[13:57] <vila> bazaar is bzr + supporting tool, that was fine
[13:57] <kfogel> vila: well, it's totally unrelated to the mac uninstaller
[13:58] <vila> yeah, that one is more puzzling :)
[13:58] <kfogel> vila: and that there's no way to delete a wrong task, or at least make it disappear (when "invalid", it is still listed on the bug by default)... sigh.
[13:59] <kfogel> vila: anyway, bug filed.  I hope someone can fix it.
[13:59] <vila> igc will certainly have a look at it
[14:41] <Tak> can I not propose a junk branch for merging?
[14:41] <Tak> (on launchpad)
[14:42] <james_w> you cannot
[14:42]  * Tak grumble, repush
[14:45] <vila> Tak: lp use stacked branches, pushing in the right project should be *far* faster (and less bandwidth intensive) than pushing to a +junk branch
[14:48] <Tak> yeah, I didn't have a project set up for this one
[15:20] <Peng> FWIW, LP used to allow changing a branch's project through the website, and it may still allow it through the API.
[16:21] <kfogel> vila: when I 'bzr push' up to my remote test project, I get this warning on the client side:
[16:21] <kfogel> This transport does not update the working tree of: bzr+ssh://kffsshtest@sp.red-bean.com/projects/deepproj/. See 'bzr help working-trees' for more information.
[16:21] <kfogel> vila: I did 'bzr help working-trees', but it wasn't clear from that whether I'm supposed to use remove-tree locally (???) to suppress the warning, or use --no-trees on the server side.
[16:22] <kfogel> vila: i.e, use --no-tree when I had created the server-side shared repos
[16:22] <vila> kfogel: do you want yo update the remote working tree ... use --no-trees is what you want I think
[16:22] <kfogel> vila: no, no update of remote tree -- just want to not get the warning.
[16:22] <kfogel> vila: I think remove-tree on the remote side is what I want
[16:22] <kfogel> testing now
[16:23] <vila> I think so, I'm pretty sure you got the warning only if a remote working tree exists
[16:24] <kfogel> vila: yup, that was the answer
[16:25] <kfogel> vila: oddly, you'll get the warning even when the remote tree *doesn't* exist, but only if it theoretically could -- that is, the remote branches were not created with --no-trees, and 'bzr remove-tree' has not been run on them.
[16:25] <kfogel> pushing to those remote branches will not create a working tree, but you'll get the warning until you configure the remote side to stop thinking that it "ought" to have a working tree.
[16:26] <vila> kfogel: if you don't configure the remote side with --no-trees, then you *want* to be warned that your working trees are not updated
[16:27] <kfogel> vila: well, if you know bzr, sure :-).
[16:27] <vila> even more if you don't IMHO, even knowing it, I keep running into out-of-date working trees :)
[16:27] <kfogel> vila: however, experience teaches me that plenty of people create remote trees without that option, but this does not actually mean they "want" working trees on the remote side.  It merely means they didn't know they needed to tell Bazaar that they didn't want that.
[16:28] <vila> kfogel: I'm pretty sure that a bzr push outside a repo creates just a branch with no working tree
[16:29] <vila> if you have created a shared repo, that's another matter though... may be the default should be --no-trees... but on the other hand, most of the time when you create a repo that's because you have many wts....
[16:29] <bialix> heya vila, kfogel
[16:30] <vila> bialix: hey
[16:32] <kfogel> bialix: hey
[21:07] <NfNitLoop> Hrmm.
[21:08] <NfNitLoop> Best-practice question with SVN:
[21:08] <NfNitLoop> I tend to develop like this.   1) Create local branch.  2) Do work on local branch.  3) Merge from upstream as needed.
[21:08] <NfNitLoop> when I'm ready to commit I merge back onto the latest upstream and push it back to SVN.
[21:09] <NfNitLoop> which is cool from my perspective, but my commit message doesn't include any of the details of my inner commits.
[21:09] <NfNitLoop> Unless I manually copy & paste them all.
[21:09] <NfNitLoop> which is a pain.
[21:10] <NfNitLoop> (I mean:  It doesn't include any of those details for SVN users.   I can see the merges in my logs, of course.)
[21:10] <NfNitLoop> any better way to do that?
[21:10] <NfNitLoop> Rebasing doesn't really work well, since having merged from SVN seems to break rebase.
[21:15] <lifeless> you can use dpush
[21:15] <lifeless> otoh I would say you should just write a clear summary commit on the merge
[21:17] <NfNitLoop> Oh, I like push.  IMO keeping as much metadata is good.
[21:17] <vila> lifeless: can't commitfromnews be tweaked for that ? (Or is it newsfromcommit ?)
[21:17] <NfNitLoop> I just want to put more of it into the comment that SVN users can read.
[21:17] <NfNitLoop> as much metadata as possible*
[21:18] <lifeless> vila: its commitfromnews; I'd start by writing a new 'commitfrommerge' plugin or so
[23:03] <spiv> Good morning
[23:13] <poolie> hi all
[23:16] <spiv> poolie: good morning
[23:20] <dvheumen> hey poolie
[23:20] <poolie> hi dan
[23:20] <poolie> i just saw your mail
[23:21] <dvheumen> poolie, okay. I hadn't expected you online so soon :P
[23:31] <GungaDin> How can I remerge a directory from a branch I someone skipped in a previous merge?
[23:32] <Peng> GungaDin: bzr merge -r 123..124 some_branch
[23:32] <GungaDin> and how can I find out where it was left out exactly? during which revision?
[23:33] <Peng> 'bzr log directory/' on the original branch, perhaps?
[23:33]  * Peng /away (maybe)
[23:34] <GungaDin> can I specify the directory I need to merge in so only the changes in it will be merged in?
[23:36] <dvheumen> poolie, thanks for the info. I'll wait a few days so the FAQ + Contributor Agreement can be updated
[23:41] <lifeless> GungaDin: yes
[23:41] <GungaDin> how?
[23:42] <lifeless> bzr merge -r x..y branch/directory
[23:48] <GungaDin> what if I need the whole directory as it looks in the latest revision (not just the latest change to that directory)?
[23:48] <GungaDin> x = 1 y = last revision?
[23:49] <lifeless> x would be 0 then, I guess
[23:51] <dvheumen> poolie, changed my mind, agreement is sent, since you've already updated me on the details.
[23:51] <poolie> thanks
[23:51] <poolie> i'm sorry it's so slow
[23:51] <poolie> i don't understand why
[23:52] <dvheumen> poolie, no problem. It's just that ... like I said ... it's lawyer stuff ... sigh
[23:53] <dvheumen> but I understand why it's necessary :)
[23:53] <lifeless> poolie: you have mail; would like to chat by voice today about it
[23:54] <poolie> oh, you're going to recommend a bulk-delete?
[23:54] <poolie> or some mail in particular :)
[23:54] <lifeless> poolie: GNU meetup talk items
[23:55] <poolie> ok
[23:59] <poolie> i think that's a good list of things