[13:12] <exarkun> How do I see what branch has been merged (not commited) into a working copy?
[13:15] <fullermd> As in the URL?  Don't think it's stored anywhere.
[13:16] <exarkun> How about the branch alias?
[13:17] <exarkun> Anything that might identify what was merged
[13:18] <w7z> the branch alias is available, but not printed by `bzr st` (just the commiter and date of the tip)
[13:18] <exarkun> The information is available after I commit from the log, since the merged revisions have a branch alias that "bzr log" will show.  But before committing?
[13:18] <fullermd> Well, the WT knows the head rev that was merged, and you could dig it up from that.
[13:19] <fullermd> Don't think there's anything in the standard UI that shows you it though.
[13:19] <fullermd> I have vague memories that qbzr does though.
[13:19] <w7z> however, merge sets the submit branch if it wasn't there before, which includes the link
[13:20] <w7z> so `bzr info` may tell you in some cases
[13:21] <exarkun> oh, so that's why I have some silly random submit submit branch for most of my trunk working copies
[13:21] <fullermd> Well, that's really only good for running through your memory and saying "was it this", since you have no way of knowing when it was set etc.
[13:21] <w7z> I think qlog does show pending merges
[13:21] <fullermd> 'd be better off looking at your shell history.
[13:21] <exarkun> fullermd: I think I'd be better off if "bzr st" showed what was merged. :/
[13:22] <fullermd> Well, it does, but it doesn't show you the revid, so you can't get at more than it shows easily.
[13:25] <w7z> ...don't leave before I can bug you into filing a bug.. >_<
[13:25] <fullermd> I think I may have filed on a while back asking for --show-ids on stat to show the revids.
[13:26] <w7z> found that one, but it's not really the same?
[13:26] <fullermd> I know I grumbled about it years back...
[13:26] <w7z> it could just be used to discover the info another way
[13:26] <w7z> bug 355649
[13:27] <w7z> really, log needs to grow a way to show pending merges
[13:28] <fullermd> I don't think it would be too hard in theory to make a revspec for the second parent of the WT.
[13:28] <fullermd> But there are a lot of nasty details.  Like, what if there are multiple, and even with that, the log would go backward forever unless the user went through extra hoops to find the first bit in that history that isn't already in the branch, and...
[13:29] <w7z> workaround mentioned in bug 56011 doesn't seem usable any more, there's no .bzr/checkout/pending-merges?
[13:29] <fullermd> I thought the revid was just in the dirstate.  Maybe that's on older formats.
[13:30] <fullermd> (dunno, really.  That's lower level than I deal with)
[13:30] <w7z> seems likely, I thought it was all in dirstate these days
[13:30] <w7z> log has to show something after you commit an octopus merge, so (naïvely) I don't think it could be that much harder to show much the same thing before the commit
[13:32] <fullermd> Because log only starts from (or ends with, depending on how you think of it) one rev.
[13:32] <fullermd> After the merge is committed, there is that one, but before on an octopus there isn't.
[13:33] <w7z> there must be ways to lie :)
[13:33] <fullermd> That would take very deep changes to how log works.  With a unique head, you just add a revspec to get the id.
[13:33] <fullermd> (which doesn't really have anything to do with log at all)
[15:42] <leo2007> is there something similar to 'git grep'?
[18:08] <fullermd> leo2007: There's a grep plugin.  How closely similar it is to git's grep command I don't know.
[19:09] <leo2007> thanks