5

I would like my post-receive hook to be responsible for updating a version file in the repo itself, under certain conditions. So, suppose I have a file version.txt in my repository, I would like the post receive hook to update a version string inside version.txt.

That would mean another push to the repo. Is this possible?

Thanks!

Jacko
  • 12,665
  • 18
  • 75
  • 126

2 Answers2

3

You can have a working directory of your repo on your server. In the post-receive, git pull on the working directory, update the version.txt as needed and commit and push. This will trigger the post-receive one more time, so be careful about how you are doing your conditional update, otherwise it will go into a cycle.

#!/bin/sh
unset GIT_DIR
cd /path/to/repo.wd
git pull
echo "new content" > version.txt
git add version.txt
git commit -m "updating version.txt"
git push origin master
manojlds
  • 290,304
  • 63
  • 469
  • 417
2

I would rather not try to make any further commit/push, but use a filter driver in order, on checkout/update to be able to generate the right content for that version.txt file (i.e. with the right version string inside)

enter image description here

The smudge script, if it is able to recognized the content of a version.txt file (i.e. it won't have the name/path of said file as parameter), would replace a template section of that file with the right information.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @VonC Is it possible to have this in the receiving repository? Since the condition for updating version.txt might only be applicable in the central / receiving repo and filter drivers are only applicable while committing ( and checking out )from local repo right? – manojlds May 09 '11 at 18:52
  • @manojolds: the idea is to *never* commit a file with that information, but to commit the script able to generate the right content whenever a downstream repo will need it. A filter driver is a declaration in a `.gitattributes` file, which can be cloned/propagated amongst repo. The fact that they aren't activated on the central repo (because you only push to those) but would be on a local repo don't change the fact that no extra commit is necessary on the central repo: you will generate the right content when and where you will actually need it. – VonC May 09 '11 at 19:59
  • Awesome. Thanks, VonC. .gitattributes seems perfect for this. – Jacko May 09 '11 at 20:18
  • Pushing a second time felt a little "odd hack". – Jacko May 09 '11 at 20:19
  • One question: smudge/clean scripts are set in the .config file. I would like all of the developers to use these scripts. If I modify the .config file in the central repo, how can everyone make sure their .config files match? – Jacko May 09 '11 at 20:25
  • @Jacko: well, the scripts aren't declared in files that are pushed/fetched, for security reason and for distributed reason (the path to said scripts might not make sense from one repo environment to another). The `.config` file from the central repo has no meaning/bearing for all the downstream (clients) repos. A system config file could have a global effect if all users are on the same server where Git is installed, but that isn't a very "decentralized" setup then. – VonC May 09 '11 at 21:15
  • Thanks. In the end, I decided to move the logic to the build script. So, the build script will update the version, based on the checkin history. – Jacko May 10 '11 at 16:51
  • @Jacko: good call, this is an information more needed in RM (Release Management) than SCM (Software Configuration Management), so your move makes sense. – VonC May 10 '11 at 16:55