[06:50] <lahwo> hello. if ive got a main branch and ive branched off the main branched and made some commits in the branch i branched off the main branch, can i merge those commits back into the main branch but be selective about it?
[06:50] <lahwo> make any sense?
[06:50] <bob2> not really
[06:50] <bob2> you can merge a prefix of the branch, but not random selections
[06:51] <bob2> workarounds include: rebase/rewrite, cherry picking or just merging the whole thing
[06:54] <lahwo> what's the command to cherry pick?
[06:54] <bob2> you can probably guess
[06:54] <bob2> I don't have bzr installed to check
[06:55] <lahwo> all right, thanks
[06:59] <gour> lahwo: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/adv_merging.html
[07:00] <lahwo> gour, that's great
[07:00] <lahwo> thanks to both
[07:00] <lahwo> :)
[08:01] <mgz> morning!
[12:28] <gour>  /me is considering to switch to bzr (from hg), but it looks that 'survival guide' is not up-to-date mentioning looms (instead of pipeline) as MQ equiv.
[12:30] <jelmer> gour: I think it might predate pipeline
[12:30] <mgz> so, I use mq with hg, but I've never felt the need for an equivalent in bzr
[12:31] <mgz> tend to use a combination of named feature branches and shelves instead
[12:31] <mgz> which are just more painful with hg
[12:33] <gour> i'd like to work on some patches and tweak them until they're ready for merge...possibly with the ability to combine several of them into one commit...what do you suggest?
[12:33] <gour> mgz: how are you, in general, satisfied with bzr in comparison with hg?
[12:35] <mgz> yup, but can't do a completely fair comparision I think
[12:35] <mgz> bzr I use for a whole range of stuff, whereas hg I've just used on a couple of really projects, and not from the admin side
[12:35] <mgz> so, python for instance, still involves me uploading a diff to their tracker
[12:35] <mgz> which isn't very dvcs
[12:37] <mgz> ^+big
[12:37] <gour> i believe that bzr might be easier/safer to use for potential contributors of our projects (mostaly windows & mac users)...that's why we do not want to consider git at all
[12:38] <gour> mgz: i believe that bzr should be good-enough for big projects as well
[12:39] <mgz> gour: right, but with bzr I know to do shared repo+lightweight checkout for those, which isn't immediately obvious for beginners
[12:40] <mgz> that said, mozilla had a pretty involved getting started doc with "do it this way", so there's no reason a project can't define workflows clearly for would be contributors
[12:41] <gour> i wonder if we'd have real need for lightweight checkouts, although it seems they are needed for pipeline, but we need to read more about it
[12:43] <mgz> it's mostly useful when you've got build artefacts that are expensive to regenerate and lots of pretty similar feature branches
[12:44] <gour> what about colocated branches? (i still have to read about them...)
[12:45] <jelmer> gour: they're not ready for production use yet
[12:46] <gour> jelmer: they will be in 2.6?
[12:46]  * gour is reading 2.6 docs
[12:47] <jelmer> gour: the basics of colocated branches are present since 2.5 (the backend side of them, APIs, etc)
[12:47] <jelmer> gour: not sure if 2.6 will have the finished UI integration
[12:48] <gour> good, good...
[12:50] <gour> mgz: is there anything you miss in bzr from hg?
[12:52] <mgz> gour: nothing relevent, I'm rather envious of their installer though
[12:52] <gour> mgz: heh, ok...being on linux no problem with installers :-)
[14:12] <jml> what's the difference between supports_diff and supports_delta on LogFormatter?
[14:14] <jelmer> jml: I think one is the file-level delta and the other the diff
[14:14] <jelmer> jml: ("bzr log -p" vs "bzr log -v")
[14:14] <jml> jelmer: ah, thanks.
[14:15] <jml> jelmer: I'm trying to add a custom log formatter, but I can't seem to get it to be passed the diff.
[14:15] <jml> even thought supports_diff = True as a class variable
[14:15] <jelmer> jml: you might have to manually request it
[14:15] <jml> Hmm.
[14:17] <jml> jelmer: thanks.
[14:18] <jml> although, hah, bzrlib.patches.parse_patches won't parse the diff that log creates
[14:21] <jml> oh wait never mind
[14:21] <jelmer> jml: what are you trying to do ?
[14:21] <jelmer> hi Noldorin
[14:22] <Noldorin> hi jelmer
[14:22] <jml> jelmer: this: http://paste.ubuntu.com/1035548/
[14:23] <jelmer> jml: ah, neat
[14:23] <jelmer> jml: related, have you seen Colin's LOC counter script?
[14:23] <jml> jelmer: yes, I believe I have.
[14:23] <jelmer> cool
[14:26] <jml> Hmm.
[14:26] <jml> I don't think there's any good way to construct the command so that -p is not required.
[14:27] <jelmer> jml: can't you manually request the diff if -p wasn't specified?
[14:27] <jml> jelmer: oh, yeah, good point.
[14:34] <jml> jelmer: heaps slower though.
[14:48] <jml> I want a way in 'bzr log' to see all of the authors of a merged commit, ideally sorted by who authored the most revisions
[14:48] <jml> this is to get around PQM marking itself as author & committer
[14:49] <jml> I see there's an author_list_registry in log
[14:50] <jml> but it only gets the revision, and I don't know how to go from that to the tree of merged revisions without a repository, and I don't know how to get a repository without implementing my own cmd_log
[14:56] <jml> ah, got an example
[14:58] <gour> i installed bzr-fast-import plugin, but attempt to import repo (from git) gives: "bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module"
[14:59] <jelmer> gour: you need to install python-fastimport too
[14:59] <gour> plugin is listed as "fastimport 0.14.0dev"
[14:59] <gour> ahh, ok
[14:59] <jelmer> gour: (not the bzr plugin, but the python module)
[14:59] <jml> actually, no, not an example :\
[15:11] <jml> can I get a log report for a list of revisions?
[15:37] <jml> hmm.
[17:52] <gour> http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/gpg_signatures.html page says: "There is still a number of digital signature related features which are hoped to be added to Bazaar soon. These include bzr explorer integration and setting branches to require signatures." (bottom) is there any concrete plan in regard?
[17:59] <lifeless> I don't believe so.
[17:59] <lifeless> jml: what do you mean
[18:00] <jml> lifeless: bzr log -r X, Y, Z to log revisions X, Y and Z
[18:01] <lifeless> jml: ah, no. Our algebra is a range definer only.
[18:15] <gour> lifeless: is there some roadmap for > 2.6?
[18:15] <lifeless> I'm not sure TBH
[18:15] <lifeless> Generally fix things, merge patches etc for sure; I don't know of specific big-ticket tasks though.
[18:16] <gour> ok
[23:06] <thomi> Hi, is there a way to get a 'bzr log' that shows all revisions that changed a particular line (or lines) in a certain file? something like 'bzr log path/to/file:10'
[23:06] <thomi> I guess the problem is that line 10 will be different across revisions.
[23:11] <mwhudson> thomi: do you want something programmatic?
[23:11] <mwhudson> i think qannotate might let you do something like that interactively
[23:11] <thomi> ideally, yes
[23:11] <thomi> oh, let me see
[23:11] <mwhudson> ah maybe it was gannotate...
[23:12] <thomi> hmm, qannotate shows me the who made the last revision to a particular line
[23:12] <thomi> but AFAICT doesn't let me search older revision for that line
[23:13] <mwhudson> thomi: gannotate has forward and back buttons
[23:13] <mwhudson> it follows logical lines though, not numbered lines
[23:13] <mwhudson> i guess you could look at what it's doing in the source
[23:14] <thomi> mwhudson: ahhh, thanks - that works perfectly
[23:14] <thomi> \o/