[MERGE] Clean up pull -v

[Aaron Bentley]

Vincent Ladeuil wrote:
>>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
> But if they were less public functions in bzrlib.log, it would be
> easier to refactor them so that show_log is used consistently
> everywhere.

I guess my point is that the interfaces we add now should be sane
interfaces.  If they are, we shouldn't need to refactor them.  If not,
let's fix them.

> It's already an anomaly that 'pull' and 'push' use
> show_changed_revisions where 'missing' use its own functions.

'missing' is showing different data from what 'pull' and 'push' show.

> <snip/>
>     >> 
>     >> Why don't you respect the log_format parameter here ?
> 
>     aaron> There's no way for a user to specify a log format
>     aaron> anyhow,
> 
> Yet. But I did an RFC about the showing revisions in a consistent
> way across all bzr commands and that includes allowing user to
> specify their preferred log format from the command line (in
> addition to the one you care and love in branch.conf :).

And still I say "yagni".  Until it's required, I don't feel the need to
add it.

> And I voted approve on your previous patch regarding pull partly
> because you were making the log_format visible just where I
> wanted it :-)

That's not where I want it, it was just the only place I could put it.

I'd much rather have an API that allowed a LogFormatter to be supplied
than an API that allowed a LogFormatter *name* to be specified.

>     aaron> so I don't see a reason to allow the command to
>     aaron> specify it.  Instead, show_branch_change determines it
>     aaron> from the branch.
> 
> <snip/>
> 
>     >> Very nice one, but until we carefully rewrite and review log to
>     >> know what should be public or not, please make it private.
> 
>     aaron> I don't see why this would be bad functionality to
>     aaron> have as public.
> 
> I didn't say it was bad, quite the contrary: "Very nice one".

I think you might be misunderstanding me.  I didn't mean "bad" in a
general sense, I meant "having this functionality publicly available
would be bad".

> I said: please, stop adding public functions in bzrlib.log, there
> are already too many there, even some evil ones that nobody
> should use (find_touching_revisions for example).

I don't understand why log is any different from branch.py or
repository.py in that respect.

> I plan a
> deprecation dance there which will already be painful, have
> mercy, please.

I don't understand why introducing good APIs would hinder deprecating
bad ones.

>     >> Clearly duplicate some code present in bzrlib.log.
> 
>     aaron> I don't think it does.
> 
> It's a combination of _linear_view_revisions + show_log.

If show_log worked for the purpose, I would have used show_log instead
of show_flat_log.  But show_log works by revno, which means it can't be
used here.

_linear_view_revisions is nothing like show_flat_log-- The equivalent
functionality would be in get_history_change.

Aaron