[MERGE] Fix #175520 by implementing a --deep option for log

[Ian Clatworthy]

Robert Collins wrote:
> On Tue, 2009-01-13 at 18:41 +0100, Vincent Ladeuil wrote:
>>
>> How about abandoning that --old option in favor of a --file-ids
>> option which will indicate that the additional arguments are to
>> be interpreted as file-ids instead of paths ?
> 
> As much as possible I'd like to avoid forcing users to use fileids. It's
> like asking a user to put in a inode to 'ls'. It may technically reflect
> the implementation but its neither necessary nor useful.

I'm OK with Vincent's suggestion - I was thinking the same thing
myself. It's useful without being smooth though.

> Well I don't think looking at multiple paths is the /actual/ use case
> here, is it? I understood the key thing was logging paths that no longer
> exist, which a revision-to-lookup-in + PATH is sufficient to accomplish.
> I'm not denying the utility of what you've written, but lets remember
> the end we're aiming for.

A fair point.

>> My current feeling is that there are too many use cases for log
>> and trying to address them all in the command itself will never
>> succeeds (or ends up with a monster nobody will ever master).
> 
> Totally agree - thats what my comment about log being a bad vehicle for
> arbitrary queries is about.

Even so, log needs to handle some "simple" cases that it can't
currently do and being able to filter on a set of file-ids
*internally* is the foundation for several of those.

I'm happy to spend some more time thinking/discussing the UI
layer but I think it's worth extending the internals in this
direction as a patch now. The first application can be extending
log to support multiple FILE arguments, not just one.

Union-logging against old names, directory logging, and other
use cases can be added once that core patch lands and the
respective UIs for each case is agreed.

Ian C.