We use SVN at work, but for my personal projects I decided to use Git. So I installed Git yesterday, and I wonder what is the revision number equivalent in Git.
Let's say we work on version 3.0.8 and every bug fix has its own revision number we can use when we talk about this bug fix. So if I tag the code in Git to 3.0.8 what then I can use as a revision number or some other more detailed kind of identification? I find the hash not so user friendly for humans.
Post build event for Visual Studio
From the Git manual, tags are a brilliant answer to this issue:
Check out 2.6 Git Basics - Tagging
Git does not have the same concept of revision numbers as subversion. Instead each given snapshot made with a commit is tagged by a SHA1 checksum. Why? There are several problems with a running revno in a distributed version control system:
First, since development is not linear at all, the attachment of a number is rather hard as a problem to solve in a way which will satisfy your need as a programmer. Trying to fix this by adding a number might quickly become problematic when the number does not behave as you expect.
Second, revision numbers may be generated on different machines. This makes synchronization of numbers much harder - especially since connectivity is one-way; you may not even have access to all machines that has the repository.
Third, in git, somewhat pioneered by the now defunct OpenCM system, the identity of a commit (what the commit is) is equivalent to its name (the SHA id). This naming = identity concept is very strong. When you sit with a commit name in hand it also identifies the commit in an unforgeable way. This in turn lets you check all of your commits back to the first initial one for corruption with the
git fsck
command.Now, since we have a DAG (Directed Acyclic Graph) of revisions and these constitute the current tree, we need some tools to solve your problem: How do we discriminate different versions. First, you can omit part of the hash if a given prefix, 1516bd say, uniquely identifies your commit. But this is also rather contrived. Instead, the trick is to use tags and or branches. A tag or branch is akin to a "yellow stick it note" you attach to a given commit SHA1-id. Tags are, in essence, meant to be non-moving whereas a branch will move when new commits are made to its HEAD. There are ways to refer to a commit around a tag or branch, see the man page of git-rev-parse.
Usually, if you need to work on a specific piece of code, that piece is undergoing changes and should as such be a branch with a saying topic name. Creating lots of branches (20-30 per programmer is not unheard of, with some 4-5 published for others to work on) is the trick for effective git. Every piece of work should start as its own branch and then be merged in when it is tested. Unpublished branches can be rewritten entirely and this part of destroying history is a force of git.
When the change is accepted into master it somewhat freezes and becomes archeology. At that point, you can tag it, but more often a reference to the particular commit is made in a bug tracker or issue tracker via the sha1 sum. Tags tend to be reserved for version bumps and branch points for maintenance branches (for old versions).
I'd just like to note another possible approach - and that is by using
git
git-notes(1), in existence since v 1.6.6 (Note to Self - Git) (I'm usinggit
version 1.7.9.5).Basically, I used
git svn
to clone an SVN repository with linear history (no standard layout, no branches, no tags), and I wanted to compare revision numbers in the clonedgit
repository. This git clone doesn't have tags by default, so I cannot usegit describe
. The strategy here likely would work only for linear history - not sure how it would turn out with merges etc.; but here is the basic strategy:git rev-list
for list of all commit historyrev-list
is by default in "reverse chronological order", we'd use its--reverse
switch to get list of commits sorted by oldest firstbash
shell togit log
with--notes
, which will also dump a commit's note, which in this case would be the "revision number"git status
)First, let's note that
git
has a default location of notes - but you can also specify aref
(erence) for notes - which would store them in a different directory under.git
; for instance, while in agit
repo folder, you can callgit notes get-ref
to see what directory that will be:The thing to be noted is that if you
notes add
with a--ref
, you must also afterwards use that reference again - otherwise you may get errors like "No note found for object XXX...".For this example, I have chosen to call the
ref
of the notes "linrev" (for linear revision) - this also means it is not likely the procedure will interfere with already existing notes. I am also using the--git-dir
switch, since being agit
newbie, I had some problems understanding it - so I'd like to "remember for later":)
; and I also use--no-pager
to suppress spawning ofless
when usinggit log
.So, assuming you're in a directory, with a subfolder
myrepo_git
which is agit
repository; one could do:So, at least in my specific case of fully linear history with no branches, the revision numbers seem to match with this approach - and additionally, it seems that this approach will allow using
git log
with revision ranges, while still getting the right revision numbers - YMMV with a different context, though...Hope this helps someone,
Cheers!
EDIT: Ok, here it is a bit easier, with
git
aliases for the above loops, calledsetlinrev
andunsetlinrev
; when in your git repository folder, do (Note the nastybash
escaping, see also #16136745 - Add a Git alias containing a semicolon):... so you can simply invoke
git setlinrev
before trying to do log involving linear revision notes; andgit unsetlinrev
to delete those notes when you're done; an example from inside the git repo directory:The time it would take the shell to complete these aliases, would depend on the size of the repository history.
The SHA1 hash of the commit is the equivalent to a Subversion revision number.
After researching in the online repositories for a long time I found that logically there is no difference between a revision number and a commit number in Git.