[11:28] <__marco> can I grep a file to search exactly when something was removed?
[11:28] <__marco> something like: bzr grep -r branch:../branch1.../ line removed
[11:29] <__marco> I know that the -r syntax is wrong but I don't know also how to specify the versions between two branches
[11:38] <fullermd> Never messed with grep.  I always just did a log -p and then searched in less.
[22:05] <rozzin> Hm. I was thinking maybe "bzr log -r annotate:..." might have been able to do that.
[22:05] <rozzin> Doesn't look like it, though.
[22:07] <fullermd> Would be hard to describe something removed like that, I'd think.
[22:08] <fullermd> Plus the issue with overspreading diffs, etc.  I always looked a little crosseyed at annotate:.
[22:14] <SamB> yeah, afaik "git blame" can't tell you "something was deleted here since the surrounding lines changed", either. (It'd be kind of nice if it could.)
[22:15] <mgrandi> i haven't evern seen that in a 'blame' command, cause the entire file could be 'deletions'....
[22:15] <mgrandi> i thought it was more for just 'who put this line here' sort of thing
[22:17] <fullermd> Defining or declaring or asking about things going away seems harder all around than things coming in.  I'll bet there are philosophical resolutions if somebody wanted to take enough time to hash it all through.
[22:18] <fullermd> Not sure about making it practical though.
[22:18] <mgrandi> it seems like it would be a separate command, it would be so much data to see all at once seeing deletions and regular 'blames' all at once
[22:18] <fullermd> An interesting ontological exercise though, I imagine.
[22:21] <rozzin> Sure enough "bzr revert -r$REV_WITH_LINE; bzr log -r annotate:..." does tell me that the line in question "does not exist in branch"....