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

[Robert Collins]

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...

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

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

>     Ian> You're solving two problems at once here but perhaps they
>     Ian> really ought to have separate solutions?
> 
>     Ian> * --name (say) for name-matching
>     Ian> * --old to search for the most recent file-id with that path.
> 
>     robert> I would say that just --old is enough as a name - I
>     robert> mean, log -v FILE today does file->fileid mapping, so
>     robert> log -v --old FILE looking for file names is not much
>     robert> different from the users perspective.
> 
> You agree on the name (I can do that too) but disagree on its
> semantic.
> 
> --deep (or let's just say --old from now on) is meant to address
> one hole: we don't have (and maybe still don't want) a mean to
> query log for a given file id.
> 
> Most of the time nobody cares, I think more than 90% of log uses
> doesn't even try to query for files that aren't present anymore
> in the current tree.
> 
> Yet, when you want to search for such a file, without --old,
> you're out of luck.
> 
> Ian makes a distinction between 'show me that previous
> file->fileid match' whereas I just implemented 'show me all the
> file->fileids matches'.

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

> I don't think we need such a distinction as long as the number of
> ids for the same path remain small (and I think it generally
> remains small).


> So, in that patch, can we agree on handling only two cases as
> done here ?:
> - file -> file id against the working tree by default
> - file -> any file id if --old is used

Fine with me.

> Otherwise we need yet another mean to access even older file ids.
> 
>     >> This patch prepares some parts to be able to address other log
>     >> related bugs like the ability to specify multiple files or
>     >> requesting the log for a directory.
> 
>     Ian> Cool.
> 
>     >> Since the revisions displayed are different when --deep is used,
>     >> I'd like feedback on the choices made (in particular, unlike the
>     >> file-id based implementation, the revisions toward mainline are
>     >> *not* displayed if they don't reference the file).
> 
>     Ian> I fully expect someone to raise that inconsistency as a bug and,
>     Ian> from a UI perspective, I don't think we can justify it. If it's
>     Ian> important to know the merge revisions when the file exists, it
>     Ian> remains important later even if the file has since been deleted.
> 
>     Ian> I'm hesitant to block this patch on this because I hate it when
>     Ian> reviewers make perfect the enemy of good. Your patch is a step
>     Ian> forward but differences like this are red flags about the
>     Ian> fragility of the implementation.
> 
>     robert> I think this should show the same revisions as log
>     robert> does today, its IMO definitely a bug.
> 
> 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:

log -v FOO
and 
log -v --old FOO

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

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

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

All the same, adding an option with spuriously different behaviour
unrelated to what the option claims to do is bad: if there isn't one
right way, then this option conflates multiple different things. If
there is one right way then either the existing one is wrong and should
change, or the new behaviour is wrong. It will also be adding more
complexity in 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]*').

Can you enlarge on why it is useless please.

> 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 ?

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

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090107/0b44c5f0/attachment.pgp