josh@xxxxxxxxxxxxxxxx schrieb am 21.01.2015 um 00:11: > 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 We do have a linear history when we walk with --first-parent :) 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. 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. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html