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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
