[MERGE][bug #172657] Graph.find_differences() and status after merge

[Ian Clatworthy]

John Arbash Meinel wrote:
> Attached is an updated form of my previous submission, which I now
> consider at least ready for review.

I'm still working my way through the changes to graph.py. So far, so
good in that file. I posted some comments yesterday about some requested
changes to the tests. I'd also like quite a few changes made to status.py.

bb:resubmit

> +        width = osutils.terminal_width()
>          try:
>              from bzrlib.osutils import terminal_width
>              width = terminal_width() - 1    # we need one extra space to avoid
>                                              # extra blank lines
>              m_revision = branch.repository.get_revision(merge)
> +            revisions = dict((rev.revision_id, rev) for rev in
> +                             branch.repository.get_revisions(merge_extra))
> +        except errors.NoSuchRevision:
> +            # If we are missing a revision, just print out the revision id
> +            if short:
> +                prefix = 'P  '
> +            else:
> +                prefix = ' '
> +            to_file.write(prefix + ' ' + merge)
> +            to_file.write('\n')
> +        else:
> +            rev_id_iterator = sorter.iter_topo_order()
> +            num, first, depth, eom = rev_id_iterator.next()
> +            assert first == merge
> +            m_revision = revisions[merge]

Hmm, show_pending_merges was looking pretty crufty before your changes.
I appreciate that the interesting/important part of this patch is the
graph.py changes but show_pending_merges needs some refactoring love
before I'd be happy to accept the new version. Here's what I'd like:

* width calculation to be pulled out of the 'for merge in pending' loop
* ditto for setting the prefix strings (prefix and mprefix say)
* replace the assert with an if ... raise
* don't set m_revision twice - the first one will do (##)
* put the sorting logic in a separate function (returning the iterator
  say) and only call it in the else of the try block

## You could just as easily drop the first one. Looking at
https://lists.ubuntu.com/archives/bazaar/2008q1/038430.html though and
Andrew's input in particular ...

> pending merges:
>   merge 1:
>     sequence #1 commit #3
>     sequence #1 commit #2
>     sequence #1 commit #1
>   merge 2:
>     sequence #2 commit #2
>     sequence #2 commit #1
> 
> Or more radically, I'd probably be satisfied with this output by default:
> 
> pending merges:
>   sequence #1 commit #3
>     (and 2 others)
>   sequence #2 commit #2
>     (and 1 other)

much of the sorting code could be skipped altogether if we only
displayed the full list in verbose mode. WE can left that bridge to
later though.

Ian C.