I'm looking for a Git alternative to "svn info".
Today I added some information 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 of 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" as well since Git is distributed.)
Update: Using rev-parse was really useful, and I got something like this:
cj@zap:~/git_test$ git rev-parse HEAD
72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8
And with that magic number it is later possible 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 in Git Tag Does the Wrong Thing by Default.
But please note that a checkout seems to work anyway, even though that was an error message.
git checkout 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8
The normal thing though 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 it can be really useful as well.