tags:

views:

340

answers:

4

Hi

I'm looking for a git alternatives to "svn info".

Today I add some info that SubVersion gives me with the "svn info" command right into my build, and that is then pushed into a source file that prints this during startup. That way I always know where that build came from and how to get it back again.

If you have "svn info" like URL, Repository Root, Repository UUID and the Revision, you have a good link between what is deployed and the buildsystem. And if someone reports a bug you know where that software came from, and since that information was automatically included the risk off human error is smaller.

Now the question is, what information do I need to get from git so I can later identify where that build came from? And how do I use that information to switch back to exactly that version?

(Maybe I need to add some information about the "build computer" ass well since git is distributed.)

Thanks Johan


Update: Using rev-parse was really useful, I got something like this:

cj@zap:~/git_test$ git rev-parse HEAD
72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8

And with that magic number it is later posible to do

cj@zap:~/git_test$ git checkout 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8

And I am back where I was.


Update: I think that if I take some parts from that scripts VonC provided and put them into my buildfile I will get the result I was looking for.


Update: A note on "git describe", you need a real tag (tag -a) earlier in you branch history to make this work or you will get something like this.

fatal: cannot describe '72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8'

The problem is also described here http://www.rockstarprogrammer.org/post/2008/oct/16/git-tag-does-wrong-thing-default/

But please note that a checkout seem to work anyway, even thou that was a error message.

git checkout 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8

The normal thing thou seems to be that you create something like a "ver1.0" tag, and then if you continue to work you get something like this:

cj@zap:~/git_test$ git describe 
ver1.0-2-g4c7a057
cj@zap:~/git_test$ git tag -a ver2.0
cj@zap:~/git_test$ git describe 
ver2.0
cj@zap:~/git_test$ git commit . -m "something..."
Created commit ac38a9d: something...
 1 files changed, 1 insertions(+), 0 deletions(-)
cj@zap:~/git_test$ git describe 
ver2.0-1-gac38a9d

So when you use describe correctly it does work and may produce a more human readable results, and can be really useful as well.

Thanks Johan

+3  A: 

In git, the commit id is unique in a project even across distibuted code. You can also checkout a commit id, so if you want an identifier than will enable you to get back to the state of the code that generated a build you just need the commit id.

git rev-parse HEAD

Of course, you probably want to be sure that there aren't any pending changes in the working tree or index so you might want to check that there's no output to something like this:

git diff --name-status HEAD

or just use the exit code of:

git diff --quiet HEAD

The only things that you might want to record about the build machine are environmental factors such as tool chain versions and what state any tools that didn't come from the repository were in.

If you have a central master repository you could record the url of that, although as the commit id is unique across all clones of the project it's not critical information for identifying the commit.

Charles Bailey
Good points. +1
VonC
+4  A: 

To complete Charles's answer, you also can make a script displaying "sn info" like information, like this one (already mentioned there)

#!/bin/bash

# author: Duane Johnson
# email: [email protected]
# date: 2008 Jun 12
# license: MIT
# 
# Based on discussion at http://kerneltrap.org/mailarchive/git/2007/11/12/406496

pushd . >/dev/null

# Find base of git directory
while [ ! -d .git ] && [ ! `pwd` = "/" ]; do cd ..; done

# Show various information about this git directory
if [ -d .git ]; then
  echo "== Remote URL: `git remote -v`"

  echo "== Remote Branches: "
  git branch -r
  echo

  echo "== Local Branches:"
  git branch
  echo

  echo "== Configuration (.git/config)"
  cat .git/config
  echo

  echo "== Most Recent Commit"
  git log --max-count=1
  echo

  echo "Type 'git log' for more commits, or 'git show' for full commit details."
else
  echo "Not a git repository."
fi

popd >/dev/null

Which would produce something like:

== Remote URL: origin [email protected]:canadaduane/my-project.git
== Remote Branches:
  origin/work
  trunk
  trunk@1309
  trunk@2570
  trunk@8

== Local Branches:
  master
* work

== Configuration (.git/config)
[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
[svn-remote "svn"]
  url = svn+ssh://svn.my-project.com/srv/svn
  fetch = my-project/trunk:refs/remotes/trunk
[remote "origin"]
  url = [email protected]:canadaduane/my-project.git
  fetch = refs/heads/*:refs/remotes/origin/*
[github]
  user = canadaduane
  repo = my-project

== Most Recent Commit
commit b47dce8b4102faf1cedc8aa3554cb58d76e0cbc1
Author: Duane Johnson <[email protected]>
Date:   Wed Jun 11 17:00:33 2008 -0600

    Added changes to database schema that will allow decentralization from content pointers table

type 'git log' for more, or 'git show' for full commit details.
VonC
It's very talkative, but there seems to be a lot of useful info in this little script ;)
Johan
@Johan: the script I mention above is quite talkative, and designed to mimic some of the "svn info" command. It is always possible to trim it down to a more concise version.
VonC
+3  A: 
git describe

is all you need. Just make sure you've created at least one (proper) tag.

Dustin
Also take a look at how Git itself and Linux kernel use it via GIT-VERSION-GEN script, and its use in Makefile to change @VERSION@ into e.g. 1.6.0-rc2
Jakub Narębski
This seems to depend on some user action... meaning it seems to be error prone and there for not really useful? or did I miss something?
Johan
I did miss something, the tag -a... added a update in my question about that....
Johan
+2  A: 

I don't know if this is what you want, but if you want to embed some kind of version info during build time, tag your point releases, and take a look how Git itself does it (Linux kernel uses the same mechanism) using Makefile and GIT-VERSION-GEN script (both links are to gitweb at repo.or.cz).

GIT-VERSION-GEN in turn uses git-describe.

Jakub Narębski