[02:37] <\u03b5> Ummm, how do I undo either unshelving or merging?
[02:37] <\u03b5> bzr unshelve slipped out of my fingers before I committed a merge
[02:39] <spiv> \u03b5: with a bit of difficulty :/
[02:39] <\u03b5> I begin to suspect that :-)
[02:39] <spiv> \u03b5: I think the simplest way is something like do the merge again in a fresh tree, then the diff between the two trees is the change you unshelved
[02:40] <\u03b5> good idea!
[02:40] <spiv> \u03b5: so perhaps make a fresh working tree, do the merge there, and commit it
[02:40] <poolie> hi spiv
[02:40] <spiv> \u03b5: then just just copy over the files from the other tree (or you might even be able to 'bzr merge --uncommitted' from it)
[02:40] <spiv> \u03b5: or something along those lines
[02:41] <\u03b5> I get the idea, thanks :)
[02:41] <spiv> Hi poolie!
[02:45] <\u03b5> yep, bzr got the hint with merge --uncommitted
[02:49] <\u03b5> well, thanks again
[05:22] <MvG> Good morning! I'm just thinking about bzr log and its --include-merges option. What it actually does is not so much about the merges themselves, i.e. the commits with two parents, but instead about the sidelines, i.e. the commits not in the left-parent-only mainline. So I wonder whether that option should be renamed to --include-sidelines, with the old name kept for compatibility but not advertised through help any more.
[05:25] <MvG> The main reason I'm thinking about this is because I believe it would make sense to have an option --exclude-merges or --without-merges that would omit any merging commit, i.e. those commits that have two parents. The rationale being that usually the merges contain little actual modifications, whereas the non-merging commits contain the changes. So especially for a change log it would be useful to only have the non-merging commits to document what c
[05:26] <MvG> But having two options, --include-merges and --exclude-merges, which don't do the opposite of one another and which are even expected to be used together would be very confusing indeed. And I believe that calling the two-parent-commits "merges" makes more sense than calling the sidelines "merges", so if you agree, I'd rather change the name of the current option.
[06:41] <mlh> oh! Et tu Spiv?
[06:41] <mlh> congrats :-)
[06:55] <vila> I'll freeze 2.4.1 today, if you have objections, yell ;)
[07:34] <poolie> hi mvg, vila
[07:34] <vila> hey !
[07:34] <vila> oh, hi MvG !
[07:34] <MvG> Hi there!
[07:35] <poolie> mvg i think the feature basically makes sense
[07:35] <poolie> of course for some branches of some projects, like bzr, everything will be a merge
[07:35] <poolie> you could change it to --include-merged
[07:35] <poolie> though perhaps a one-character difference is confusing in other ways
[07:35] <MvG> poolie: I'd have it --include-sidelines by default, overridable.
[07:36] <poolie> i mean rather than 'sidelines' you could call them 'merged'
[07:36] <MvG> Ah, sorry, my misunderstanding.
[07:37] <MvG> Hmmm. Rather asking for confusion, without giving any benefits, as any form of backwards compatibility depends on no change at all.
[07:37] <MvG> So if you have to change it, it doesn't matter by how much.
[07:37] <MvG> And I believe "sideline" is the well established bzr term for these things, right?
[07:49] <MvG> By the way: can you reproduce bug #842695, or is there something broken in my local clone?
[07:49] <ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
[07:50] <MvG> In other words, do you get the same unrelated commits, or do you get the ones I'd have expected?
[08:02] <poolie> we do call them 'mainline'
[08:02] <poolie> not specifically 'sideline' that i've heard, or not so commonly
[08:02] <poolie> but it's probably a pretty good name for it
[08:06] <poolie> mvg, so regarding bug 842695
[08:06] <ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
[08:07] <MvG> yes?
[08:11] <poolie> sorry, phone
[08:11] <poolie> so john seems to be saying that if you don't give --include-merges
[08:12] <poolie> it tells you about the nearest inclusive mainline commit
[08:12] <poolie> which i think is reasonable
[08:12] <poolie> otherwise --no-include-merges would tend to print nothing
[08:12] <poolie> it does mean it's more than just filtering though
[08:12] <poolie> so then there are two questions
[08:12] <poolie> - is it getting it wrong
[08:12] <poolie> and is a better behaviour possible
[08:31] <jam2> morning all
=== jam2 is now known as jam
[08:44] <poolie> jam, can pqm-submit work with a non-local source branch?
[08:47] <vila> poolie: IIRC that's what spiv change was about months ago, --ignore-local and --public-location ?
[08:48] <jam> poolie: i've never tried the non-local thing
[08:48] <jam> I generally copy it and use --public-location
[08:48] <jam> but I think vila has a point
[08:48] <vila> poolie: revno 61 in the pqm plugin
[08:48] <jam> if you --ignore-local it shouldn't care
[08:50] <vila> arf, and this revno introduces a StackedConfig in pqm-submit... jelmer, yet another use case for stacks
[09:22] <Riddell> so do we have a shiny new PQM?
[09:29] <poolie> hi jam, i'll try to reply about metadir/colo stuff later
[09:29] <poolie> i'm inclined towards having it in trunk though
[09:29] <poolie> but i'll try to explain this
[09:29] <poolie> or to catch you to talk about it
[10:00] <vila> Riddell: not yet, mthaddon is working on it, auth issues (see #launchpad-ops)
[10:09] <MvG> poolie: Sorry, read your reply only now. Wrt bug 842695: when listing mainline commits only, it is doing the right thing. It is only when including sidelines that it somehow selects completely wrong commits, which apparently have nothing at all to do with the path specification given as an argument.
[10:09] <ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
[10:10] <MvG> I guess it's somehow related to the fact that the dir was once a separate branch which was later joined, but that in itself isn't enough for a test case reproducing this.
[10:11] <jelmer> vila: I'm not opposed to stacks, I like them. I don't see the use case for a stack registry yet though
[10:11] <vila> jelmer: right *yet* is probably the key word here ;)
[10:44] <vila> jelmer: liaise with mthaddon if your current pqm submission fails or exhibit any weird behavior, you're on the new pqm \o/
[10:58] <jelmer> vila: I can tell, it's fucking quick
[10:58] <vila> :)
[10:59] <vila> jelmer: and that's without /tmp as tmpfs nor --parallel :-D
[11:03] <mthaddon> it's succeeded
[11:03] <mthaddon> I'm about to go to lunch, but after lunch will get tmpfs set up and log syncing sorted
[11:04] <jelmer> mthaddon: Thanks *very* much for setting that up!
[11:04] <mthaddon> you're welcome
[11:04] <mthaddon> now if launchpad would just update https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev ....
=== ccxCZ_ is now known as ccxCZ
[11:22] <vila> mthaddon: bzr missing tells me jelmer's patch has landed
[11:23] <jelmer> yeah, Launchpad has now picked it up as well
[12:23] <MvG> jelmer: is the fix for bug 842993 a real bug fix or rather an improvement?
[12:23] <ubot5> Launchpad bug 842993 in Bazaar "reconfigure silently ignores one of two requests" [Medium,Triaged] https://launchpad.net/bugs/842993
[12:35] <MvG> Sinde when does bzr accept translations on lp? Thinking about doing a bunch of German ones...
[12:36] <Riddell> MvG: since yesterday
[12:36] <Riddell> I haven't made an announcement yet
[12:37] <Riddell> but go ahead, it would be good to have a real language to test with, and keep an eye out for problems which can be reported to me
[12:44] <MvG> Reasonable positions for line wraps are hard to decide in the LP UI with its variable-width font for the translation boxes...
[12:44] <MvG> Fixed width for both original and translation and boxes at 80 cols would be better.
[12:48] <MvG> Ah, as I'm not an official LP translator, I can only make suggestions, but they don't count as translations, even in the absence of official translations. Well, so be it.
[12:49] <Riddell> I was strongly advised to set that else the quality of translations is very poor
[12:49] <Riddell> I'm sure it can be hard for you to join the translations team
[12:50] <Riddell> you could also just translate the .pot file directly
[12:57] <jelmer> MvG: either way, it's a good change :)
[12:58] <jelmer> MvG: I'm not sure if it should be for IMPROVEMENTS or BUG FIXES, up to you
[12:58] <jelmer> how upset were you when it didn't do what you expected ? :)
[13:01] <MvG> Not at all upset about it not doing the stuff I wanted, but rather annoyed about it not printing any warning. After all, I expect commands to either succeed ot tell me about it. Pushed it as a bug now.
[13:03] <MvG> Riddell: Joining the team isn't an option, otherwise I'd feel obliged to do more translations than I can reasonably afford. I'd rather write useful apps in that time.
[13:03] <MvG> I won't do a full translation of bzr for the same reason, but will see how far I get.
[14:11] <MvG> jelmer: do you need another merge proposal to merge the release notes from lp:~gagern/bzr/bug842993-reconfigure ?
[14:11] <jelmer> MvG: please
=== mnepton is now known as mneptok
=== shadeslayer_ is now known as shadeslayer
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
[17:10] <lamalex> hey guys,  i can never remember the syntax for doing this.. i want to revert out a single revision that is not HEAD
[17:10] <lamalex> it's not just bzr revert -r 36 is it?
[17:10] <lamalex> given rev 36 is the one i want to pull out
[17:11] <Peng>   To remove only some changes, without reverting to a prior version, use
[17:11] <Peng>   merge instead.  For example, "merge . --revision -2..-3" will remove the
[17:11] <Peng>   changes introduced by -2, without affecting the changes introduced by -1.
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
=== Meths_ is now known as Meths
[22:46] <poolie> hi all
[23:13] <Noldorin> hey jelmer