Re: Pretty format specifier for commit count?

[josh@joshtriplett.org]

On Tue, Jan 20, 2015 at 04:49:53PM -0500, Jeff King wrote:
> On Mon, Jan 19, 2015 at 05:17:25PM -0800, Josh Triplett wrote:
> 
> > > Can you be a bit more specific about the type count that you are after?
> > > "git describe" counts commits since the most recent tag (possibly within
> > > a specific subset of all tags). Is that your desired format?
> > 
> > That might work, since the repository in question has no tags; I'd
> > actually like "commits since root commit".
> 
> That's basically a generation number. But I'm not sure if that's really
> what you want; in a non-linear history it's not unique (two children of
> commit X are both X+1).

That would actually be perfectly fine.  If I need to distinguish
branches, I can either use branch/tag names, or append a commit hash.  I
don't mind the following:

 /-B-\
A     D
 \-C-/

A=1
B=C=2
D=3

I could (and probably should) append "+hash" to the version number for
uniqueness, and if I care what order B and C sort in, I can use tags,
branches, or some other more clever mechanism.

> It sounds like you really just want commits
> counting up from the root, and with side branches to have their own
> unique numbers. So something like:
> 
>        C
>       /
>   A--B--D
> 
>   A=1
>   B=2
>   C=3
>   D=4
> 
> except the last two are assigned arbitrarily. You need some rules for
> linearizing the commits.

I don't care about the numbers assigned to anything not reachable from
the committish I start from.

> But that's not deterministic as you add more starting points (either new
> ref tips, or just new merges we have to cross). For example, imagine
> this:
> 
>          G--H
>         /    \
>        C--E   \
>       /    \   \
>   A--B--D---F---I
> 
> If we start at I, then we might visit H and G first, meaning we learn
> about C much earlier than we otherwise would. Then we hit F, and get to
> C from there. But now it it may be in a different position with respect
> to D!

Right, the numbers need to always stay the same as you add more commits
over time.  If walking a given graph assigns a given set of generation
numbers, walking any subgraph should assign all the same generation
numbers to the common nodes.

> I suspect your problem statement may simply assume a linear history,
> which makes this all much simpler. But we are not likely to add a
> feature to git that will break badly once you have a non-linear history. :)

Not assuming a linear history, but assuming a linear changelog file. :)

> I think in the linear case that a generation number _would_ be correct,
> and it is a useful concept by itself. So that may be the best thing to
> add.

Sounds good to me.

- Josh Triplett