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

[Vincent Ladeuil]

>>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:

    robert> On Tue, 2009-01-06 at 15:19 +0100, Vincent Ladeuil wrote:
    Ian> So I'd prefer an option name that emphasized that
    Ian> aspect. (In comparison, --deep *could* one day be used
    Ian> to ask for deep searching of the path -> file-id
    Ian> mapping, i.e. look in inventories until you find the
    Ian> file-id and then log against it.)
    >> 
    >> With the caveat that you will find the first previous file id
    >> when there can be several...

    robert> I figured it was the case that what you had implemented searched for
    robert> anything-at-that-path-once.

    robert> I'd like to note that there is really some conflation
    robert> here. You could equally say that people should do
    robert> "bzr search path:NAME"; "bzr log -r X NAME". (Not
    robert> that bzr search has a path: qualifier just yet).

...and not that 'bzr log -r X FILE' use X inventory to find FILE id.


<snip/>

    robert> I think --old selecting all the ids that ever matched
    robert> the name is an ok thing to do today.

Ok.

<snip/>

    >> 
    >> Right, I mentioned that to get feedback, I got feedback :-)
    >> 
    >> I should have explained my motivations better though (but I'd
    >> really like if Robert could elaborate on why he thinks it's a
    >> bug?): I view the actual display of the merging revisions as a
    >> bug or a misfeature or may be just one more missing option due
    >> to:

    robert> log -v FOO
    robert> and 
    robert> log -v --old FOO

    robert> should IMO show the exact same revisions, for the
    robert> common case: FOO is present in the tree, and only
    robert> wt.path2id(FOO) ever held the path FOO.

    robert> So regardless of your arguments about what should be
    robert> shown, it should be the same *in both cases*.

    >> So I think *that* patch is just scratching the surface of a
    >> deeper problem.

    robert> All the same, adding an option with spuriously
    robert> different behaviour unrelated to what the option
    robert> claims to do is bad:

... yes :-/

    robert> if there isn't one right way, then this option
    robert> conflates multiple different things.

I think that the case. I'll write some tests to better highlight
the differences and ease the discussion.

    robert> If there is one right way then either the existing
    robert> one is wrong and should change, or the new behaviour
    robert> is wrong. It will also be adding more complexity in
    robert> the log code.

    robert> I don't like it because, it makes log -v FILE
    robert> meaningless, every leaf revision will show just the
    robert> files name.
    >> 
    >> And the associated action yes (added, modified, deleted). That's
    >> meaningful for me.
    >> 
    >> Note that the main motivation here is that log -v FILE on big to
    >> huge working trees is actually *useless*, the generated output
    >> also being impossible to grep unless we make it possible to use a
    >> different format (see the thread named '[RFC] About log [-v]
    >> [--deep] [file|dir]*').

    robert> Can you enlarge on why it is useless please.

Sure, when used in a large WT, with heavy merges (think hundreds
of files modified/renamed/deleted, yes this is a real life
example) you get hundreds of lines per revision: useless (or
should I have said: unusable ?). Filtering the delta in that case
clearly enhance the S/N ratio...

That's why I implemented it, but now that you mention it... 

I can imagine both usages (when the WT is smaller) so that
could/should be one more option and -v/-vv sounds about right for
that...

    >> Since it sounds that both points of view can't be
    >> reconciled, do we need one more option or should we just
    >> use verbosity_level ?  In that case '-vv' will restore the
    >> previous behavior ?

bzr log -v FILE: only output FILE related lines
bzr log -vv FILE: whole delta

bzr log -v: ??? whole delta ?
bzr log -vv: ??? whole delta ?

<shudder>

   robert> Lets just tackle one thing at a time, thats usually
    robert> easier to get agreement on. This merge claims to be
    robert> for '--deep', which I think Ian and I are both happy
    robert> with, with a better name.

Right in the heart... looks like I didn't focus enough (I tried
though...)

Let's try to refocus:

 bzr switch-threads log-deep delta-show-with-path-filter; bzr send
bzr: ERROR: unknown command "switch-threads"

Too bad :-)

Let's continue to discuss both subjects please even if I end up
doing two submissions, most of the tests for --deep^W --old
suppose that the delta is filtered.

    Vincent