[MERGE] left align log output if it only contains merge revisions

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kent Gibson wrote:
> Firstly, I don't blame you, the underlying problem is that the role of
> the RM hasn't been sufficiently well defined.  That isn't your fault.
> As I've eluded to before, my opinion is that the RM should be the
> benevolent dictator for a month.

I really don't think we should lay this on the RM at all.  People should
not need that extra prompting.

Unfortunately, I have found that they do.  In this past release cycle, I
have had several patches go un-reviewed until warned that I would bypass
the review process and submit unreviewed patches.

Reviewing isn't really related to releasing.  It should always be done
promptly, because a patch may go through several cycles before merge.

And the RM doesn't really have the authority to make people act, only to
encourage them.

> My view was, and pretty much still is, that revisions are equal, and
> that as Andrew pointed out above, my expectation was that revision
> logs are flush aligned, not that mainline revision logs are flush
> aligned.

> Aaron's view is that mainline revisions have a special place in
> bazaar

I'm not sure whether you mean that the specialness of mainline revisions
is my view only.  It's not.  It's a design decision that has affected
many things:

- - the assignment of revnos
- - the way "pull" describes what it did
- - the fact that "merge --pull" is not the default behavior
- - the behavior of "status" when there are pending merges
- - the behavior of missing
- - the behavior of log --short and log --line
- - the append_history_only flag for branches
- - the Branch api

> , and deserve the left margin to themselves.

It would be much mess controversial to say "mainline revisions are
special, but that doesn't mean that the left margin must be reserved for
them."

If you want to say "mainline revisions aren't special", then please see
our debates with the git folk.  Some VCSes take that approach, but we don't.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGi5qn0F+nu1YWqI0RArYOAJ9V4lkSemLNKu8YbEarVth2iiwM5gCghHRT
+st2mBYCpuI4UCeBenzP7/k=
=T8j1
-----END PGP SIGNATURE-----