git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Subversion-style incrementing revision numbers

From
Shawn Pearce <spearce@spearce.org>
Date
Sep 19, 2006, 22:33 UTC
Message-ID
<20060919223350.GD11601@spearce.org>
In-Reply-To
<Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com>
Joel Dice <dicej@mailsnare.net> wrote:
Show 8 quoted lines
> 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.
Previous: Joel DiceNext: Johannes Schindelin
Message 6 of 28 in “Subversion-style incrementing revision numbers”
  1. Joel DiceSep 19, 2006
  2. Petr BaudisSep 19, 2006
  3. Joel DiceSep 19, 2006
  4. Petr BaudisSep 19, 2006
  5. Joel DiceSep 19, 2006
  6. Shawn PearceSep 19, 2006
  7. Johannes SchindelinSep 19, 2006
  8. Shawn PearceSep 19, 2006
  9. Jakub NarebskiSep 19, 2006
  10. Linus TorvaldsSep 19, 2006
  11. Petr BaudisSep 19, 2006
  12. Linus TorvaldsSep 19, 2006
  13. Joel DiceSep 19, 2006
  14. Jakub NarebskiSep 20, 2006
  15. Joel DiceSep 20, 2006
  16. Junio C HamanoSep 20, 2006
  17. Robin RosenbergSep 20, 2006
  18. Petr BaudisSep 20, 2006
  19. Junio C HamanoSep 20, 2006
  20. Jakub NarebskiSep 19, 2006
  21. Petr BaudisSep 19, 2006
  22. Jakub NarebskiSep 19, 2006
  23. Joel DiceSep 19, 2006
  24. Shawn PearceSep 19, 2006
  25. Shawn PearceSep 19, 2006
  26. Joel DiceSep 19, 2006
  27. Shawn PearceSep 19, 2006
  28. Joel DiceSep 19, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.