Would it be fine if the "version file" was only created in the working
directory and not push on the server? And instead of using the date of the
last checkout it was the date of the last commit? You use the term "push"
in your reply but I get the felling it could be replaced with "written".
I suggest a simple script, ie update_version.sh, or maybe you already have
a script to generate the documentation, so you can add the commands in it.
You can have the name of the current branch with this command:
git symbolic-ref HEAD 2>/dev/null
and the date of the last commit with:
git log -n1 --tformat="%cd"
If you absolutely want the checkout date, I do not see how it can be made.
I though about cheating and use the date of .git/HEAD but it do not change
on a pull. It only change on checkout.
git offers the command "describe" who can be used to generate a version
string, but it needs a tag and it is not confined to one branch. I do not
think it is want you want, but I mention it just in case. Said you have a
tag v1.0 and 13 commits since then, describe will returns v1.0.13.
On Sunday, October 28, 2012 8:57:37 AM UTC-4, Philipp Kraus wrote:
> Thanks for your answer
> Am Sonntag, 28. Oktober 2012 12:50:15 UTC+1 schrieb Thomas Ferris
>> This reminds me of a similar but related question: How can we get SVN's
>> keyword substitution in Git.
>> The short answer is: you can't. But when you think about it, this file
>> you want to create is actually just duplicating information which exists
>> elsewhere. The right way to go about it is to find some step in your
>> build/deployment mechanism, and create this file on the fly. We build our
>> products using Maven and Gradle, and both these build-tools have places
>> where we can hook in and generate a version.txt file with interesting
>> information from Git.
> I think it is not a real keyword subsitution, because Git does not store
> any information about numbering or anything else. In my depolyment process
> it should be used for creating the documentation, so I need the "date of
> the checkout" and the branch / tag name. This information are in the repo
> all time, so I need only to push them into a code file on the checkout.
> Another way is to create it on checkout, as suggested in the git-scm.combook:
>> From http://git-scm.com/book/ch7-2.html:
>> SVN- or CVS-style keyword expansion is often requested by developers used
>> to those systems. The main problem with this in Git is that you can’t
>> modify a file with information about the commit after you’ve committed,
>> because Git checksums the file first. However, you can inject text into a
>> file when it’s checked out and remove it again before it’s added to a
>> commit. Git attributes offers you two ways to do this.[...]
> I have read this chapter and I don't want modify the file on commiting. I
> have a central repo in which each local repo is pushed, the documentation
> is created on the server. I have create a post-received hook for doing
> this, but I would like to add some information of the actually code before
> the documentation is created
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at