Subject: Re: Subversion-style incrementing revision numbers

From: Shawn Pearce <[email-masked]>
Date: Tue, 19 Sep 2006 18:33:50 -0400

Joel Dice <[email-masked]> wrote:
> The scenario I envision is several developers, each with a clone of a 
> shared repository.  The clones would not have IRNs turned on, only the 
> shared repository.  So, when I do a "git push", I get an IRN back, and I 
> am not confused, because I know that IRN only applies to the shared 
> repository.  Then, when I mark a Bugzilla bug as fixed and attach the IRN 
> to it, everybody knows that IRN refers to the shared repository.  After 
> all, I wouldn't mark the bug fixed if I had only committed it to my own 
> private repository.

How about recording the Bugzilla bug id in the commit message (such
as by simply mentioning "bug 123") and having an update hook on the
central repository extract that from the commits being pushed and
posting an update to the Bugzilla database?  The update can include
the branch name the commit(s) were pushed into and the final commit
SHA1 (or say 8 character abbreviation).

Its automatic and its easy for the developers.  I'm (sort of) doing
this for a system that's a lot more difficult to use than Bugzilla.
My fellow developers are very happy.
 
> That's what I figured.  I should be able to walk the commit chain to get 
> at all the commits in a push or fetch, right?

In the update hook you get 3 args:  refname oldsha1 newsha1

You can get the list of commits you are "receiving" during the single
push operation from:

	git log --pretty=raw $2..$3 

a quick parse for "bug (\d)+" on that text, make a set of of IDs
to update, then go update then storing the first 8 characters of
$3 and $1 (the branch name) into your bug tracker.

I said "receiving" in air quotes as you may already have some or
all of those commits in the current repository; they just are part
of other branches other than the one being pushed into.

Later another developer can ask if the fix for bug 123 is in any
given branch by looking at

	git log master..$idfrombug

where 'master' is any branch and $idfrombug is the 8 character
abbreviation you stored into the bug record in the update hook.

If this returns no output then the bug fix is contained in the
branch master; if it returns output then those are the commits
which were considered to be part of the bug fix that aren't in the
branch master.

-- 
Shawn.