> Second, in my opinion revision numbers are not that useful for > projects with large number of commits (where revision number might be > something like r4321), and nonlinear history (you don't know how r4555 > relates to r4556: they might be on different branches). For projects that do have a central authority (e.g. internal corporate projects), revision numbers make more sense. Granted, they are on separate branches (like svn), but the nice thing about them is that they are monotonically increasing. E.g. our qa people love numbers--the bug fix ticket says dev just put in r100...qa/production box says it is on r95. Doesn't matter the branch/whatever, they know the box doesn't have r100. Now, right, if its r105, it is trickier, although we also throw in branch name (e.g. topica-r100) which means no false positives but can lead to false negatives. Per Robin's response and then a thread on the list a year+ ago, a hook+tags can be used to fake this, and we're doing that now. I've been meaning to put our hooks repo up somewhere, as we've got several fun hooks that are focused on an internal/centralized workflow, but I haven't gotten to it yet. For now I've just attached the commit numbers script. For our team, lack of monotonic version numbers was a big deal--as in can't use git sort of big deal. I wouldn't be surprised if it is a contributing factor that keeps other people, especially internal teams, from git. I understand all of the reasons it can't be in git proper, but an FAQ entry about the hook/tag hack or link to a contrib script might be useful (not necessarily the one attached, given its functions/etc. baggage). - Stephen
Attachment:
functions
Description: Binary data
Attachment:
post-receive-assign-commit-numbers
Description: Binary data
