From: Shawn Pearce <spearce@spearce.org>
To: Joel Dice <dicej@mailsnare.net>
Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org
Subject: Re: Subversion-style incrementing revision numbers
Date: Tue, 19 Sep 2006 18:33:50 -0400 [thread overview]
Message-ID: <20060919223350.GD11601@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com>
Joel Dice <dicej@mailsnare.net> 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.
next prev parent reply other threads:[~2006-09-19 22:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-19 21:07 Subversion-style incrementing revision numbers Joel Dice
2006-09-19 21:18 ` Petr Baudis
2006-09-19 21:42 ` Joel Dice
2006-09-19 22:00 ` Petr Baudis
2006-09-19 22:24 ` Joel Dice
2006-09-19 22:33 ` Shawn Pearce [this message]
2006-09-19 22:40 ` Johannes Schindelin
2006-09-19 22:39 ` Shawn Pearce
2006-09-19 21:58 ` Jakub Narebski
2006-09-19 21:51 ` Linus Torvalds
2006-09-19 22:06 ` Petr Baudis
2006-09-19 22:20 ` Linus Torvalds
2006-09-19 23:35 ` Joel Dice
2006-09-20 0:15 ` Jakub Narebski
2006-09-20 16:13 ` Joel Dice
2006-09-20 7:46 ` Junio C Hamano
2006-09-20 17:28 ` Robin Rosenberg
2006-09-20 18:22 ` Petr Baudis
2006-09-20 19:07 ` Junio C Hamano
2006-09-19 22:07 ` Jakub Narebski
2006-09-19 22:11 ` Petr Baudis
2006-09-19 22:17 ` Jakub Narebski
2006-09-19 23:07 ` Joel Dice
2006-09-19 22:18 ` Shawn Pearce
2006-09-19 22:23 ` Shawn Pearce
2006-09-19 22:30 ` Joel Dice
2006-09-19 22:09 ` Shawn Pearce
2006-09-19 22:40 ` Joel Dice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060919223350.GD11601@spearce.org \
--to=spearce@spearce.org \
--cc=dicej@mailsnare.net \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).