Re: Numeric Revision Names?

For projects that do have a central authority (e.g. internal corporate
projects), revision numbers make more sense.

Surely!

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.

Yes

haven't gotten to it yet. For now I've just attached the commit
numbers script.

It would be good to have this feature in git.

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

Yes, it's true that this is a big deal for many people out there.

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).

That would be helpful, if it cannot go in git proper for real in the
centralized model.

(I also face/faced a situation where "monotonic revision numbers" were
essentially a check box item on a required list of SCM features, so
despite whatever I/the-git-team/etc. thought about their technical
inferiority, it was a criteria that could have ruled git out for us.
Hence my mentioning an FAQ entry for others faced with my same
political situation.)

This is so true in a corporate environment with centralized
repositories, then I completely agree
that in the case git is being used in this model (many companies are
really used to that), the
monotonic revision number is helpful and sometimes is showstopper to
not have them.

Regards,
-- 
[]s,
André Goddard