On Fri, Oct 03, 2008 at 11:55:57AM -0500, Stephen Haberman wrote:
> 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.
If you are constraining yourself to a central repo, then you could just
add a receive hook that tags each new commit with a monotonically
increasing revision number. Clients would get the tags upon fetch.
Something like the following (totally untested, and probably needs to
handle locking and errors more sanely) in the post-receive hook:
n=`cat revnumber 2>/dev/null || echo 0`
while read old new branch; do
git rev-list $old..$new |
while read rev; do
n=$(($n+1))
git tag r$n $rev
done
done
echo $n >revnumber
-Peff
--
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
