colocated branches and auto nicknaming may solve merge&push problem.

[Stephen J. Turnbull]

INADA Naoki writes:

 > I don't know how git solves "left most revision" problem.

I assume you're referring to distinguishing among merge parents?  Like
most things in git where "TOOWTDI" doesn't apply, it doesn't handle
it.  The git community doesn't really have a notion of a distinguished
mainline AFAICS.  It rather concentrates on reachability.  Eg, here's
a git show-branch for my personal cvs2svn workspace (this is the whole
thing):

! [master] LOD marking debug code.
 ! [old-upstream] Update cvs2svn trunk to 5022.
  ! [upstream] Update to upstream r5031.
   ! [4879+hacks] Fixup unlabeled branch names (can't contain slashes).
    * [5031+hacks] Merge branch 'upstream' into 5031+hacks
-----
    - [5031+hacks] Merge branch 'upstream' into 5031+hacks
  + * [upstream] Update to upstream r5031.
   +* [4879+hacks] Fixup unlabeled branch names (can't contain slashes).
   +* [4879+hacks^] Unlabeled branch name hack.
   +* [4879+hacks~2] Make CVS more quiet for >2.3.0 cvs2svn.
  ++* [upstream^] Update to approximately 2.3.0 release (r4879).
+     [master] LOD marking debug code.
+     [master^] Unlabeled branch name hack.
+     [master~2] Make CVS more quiet for >2.3.0 cvs2svn.
++    [old-upstream] Update cvs2svn trunk to 5022.
+     [master~4] Don't share numerical branches across files.
++++* [upstream~2] Importing cvs2svn trunk into git at revision 4809.

The order of branches follows the command line arguments.  Here I used
--all, and it looks like it's alphabetical.

I don't know exactly how the order of commits is computed, but
heuristically it has two prominent features: the current HEAD and its
immediate descendants "float" to the top, and rather than focusing on
branches and merges per se (in fact, the merges of old-upstream back
into mainline, and of upstream into 5031+hacks aren't even shown), you
can see the mainline and important branches as "thick" places.
Similarly, in gitk I believe that branches sprout from a node from
left to right in order they appear in the commit.  This often results
in a rather twisty graph in gitk, whether from git-based development
or cvs2svn/git conversion, because many git users don't distinguish
between merging from trunk into their branch and vice versa until just
before actually pushing back to the mainstream (and sometimes not even
then).

I'm sorry for going on at such length, but I think this displays quite
well the git developers' nearly complete lack of concern for this
issue which is often a focal point for Bazaar.