Re: Pretty format specifier for commit count?

[Jeff King <peff@peff.net>]

On Thu, Jan 22, 2015 at 11:10:42AM +0100, Michael J Gruber wrote:

> We do have a linear history when we walk with --first-parent :)

Yes, but I do not think it is robust to adding new commits on top. E.g.,
given:

  A--B--C---F
      \    /
       D--E

a --first-parent walk from F will show F-C-B-A. Now imagine the branch
advances to I:

          G--H---I
         /      /
  A--B--C---F--J
      \    /
       D--E

A walk from I will show I-H-G-C-B-A. F is no longer mentioned at all,
and A, B, and C are now at different positions.

This might be OK in Josh's case. I have an intuition that commits can
only be _removed_ in this case. Which means position from the _top_
might change, but the position from the root will always be the same
(and that is what he wants to be stable).  But I did not think hard
enough to convince myself that this is always the case.

> So, for the changelog for commits "on a branch", where "on a branch" is
> not the git concept but defined by "git rev-list --first-parent" (more
> like hg branches), the count from root would be deterministic and the
> right concept given the appropriate branch workflow.

Certainly the distance to root is deterministic. But I think we are
really counting "number of commits to be output between the root and
this commit". I guess if:

  1. You only ever start from one traversal point.

  2. You are picking only one parent for each merge.

then we know that our queue of commits to examine only ever has 0 or 1
items in it. And therefore a commit is either shown in the same
position from the end, or not shown at all. Because once we get there,
it is deterministic which commits we will show.

> Generation numbers are monotonous but may increase by steps greater than
> 1 on that "branch" if I remember them correctly. I.e., merge commits are
> "weighted" by the number of commits that get merged in.

Sort of. It is the longest distance to (any) root from the commit. So it
is the max() of the generations of the parents, plus one. So for a
simple branch/merge between two lines of development, the increase is
the number of commits that are merged. But a branch that has its own
branches will not increase the generation count by the total number of
commits, but rather by the longest individual sub-branch.

-Peff