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

Subversion-style incrementing revision numbers

From
JDJoel Dice <dicej@mailsnare.net>
Date
Sep 19, 2006, 21:07 UTC
Message-ID
<Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
Hello, all.

I'm considering adopting Git for a medium-sized project which is currently managed using Subversion. I've used Git for a few smaller projects already, and the thing I've missed most from Subversion is the convenience of incrementing revision numbers. The following is a proposal to add this feature to Git.

Rationale:

Incrementing revision numbers (IRNs - an acronym I just made up) are useful in that they can be treated as auto-generated tags which are easier to remember and communicate than SHA hashes, yet do not require extra effort to create like real tags. Also, they have the advantage of being chronologically ordered, so if I assert that a bug was fixed in revision 42 of a shared repository, everyone may assume that revision 45 has that fix as well.

Proposal:

As with Subversion, the IRN state in Git would be specific to a given repository and have no significance beyond that repository. Also like Subversion, IRN state would be global across a repository, so that a commit to any branch would increment the current IRN value. Every Git command taking a revision parameter would accept an IRN using a syntax such as "r$IRN". Every commit would report the IRN to the user as well as the SHA ID. The IRN feature could be enabled or disabled via a configuration option.

Implementation:

A simple, efficient implementation of this feature would be based on a single file, $GIT_DIR/history, which would contain a newline-delimited list of SHA commit IDs in chronological order, oldest first. The current repository IRN would be calculated as the size of that file divided by the SHA+newline length, and the commit ID of any IRN could be determined by seeking to the correct offset in that file. Every commit would cause a new line to be appended to the history file with that commit's ID. Finally, a history file could be generated for an existing repository by serializing the commit history based on chronological order.

I'd be happy to put together a patch that implements this, but first I'd like to get some feedback. If something like this has already been proposed, please point me to the discussion. Thanks.

  - Joel
Next: Petr Baudis
Message 1 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.