On Thu, Sep 14, 2006 at 12:15:03PM -0700, Junio C Hamano wrote: > Dave Jones <davej@xxxxxxxxxx> writes: > > The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git > > When the build procesure assigns the version to the generated > git binary, it does these checks and takes the first one: > > - Run "git describe" at the top of the source tree. If it > returns some version (not an error message), use it. This > case should not apply here since we are talking about a > tarball of a working tree, and it does not have a repository. On the server this is running on, the returns v1.3.3-g7f7e6ea > - See if 'version' file exists at the top of the source tree, > and uses what is recorded there. This file is placed in the > resulting tarball by the "make dist" target of the toplevel > Makefile. > - Otherwise use DEF_VER hardcoded in GIT-VERSION-GEN script. > The 1.4.2 series is shipped with DEF_VER set to v1.4.2.GIT, > so this does not explain why Nashanth sees "1.3.GIT" (or > "v1.3.GIT", if the original report did not copy it right). > > I just snarfed your snapshot tarball from a few days ago, and I > do not see any version file there (which indicates that it is > not a product of "make dist"). Interestingly enough DEF_VER is > set to v1.3.GIT in GIT-VERSION-GEN. This line was changed from > v1.3.GIT to v1.4.GIT with commit 41292dd on June 10th and then > updated to v1.4.2.GIT with commit 5a71682 on August 3rd. > > So a short conclusion is that the directory you are tarring up > does not have snapshot of my tree. > > I would like to understand why. If an automated 'pull' is > failing, that is somewhat worrysome, because I presume you do > not do any development of your own in your snapshot directory > and in that case everything should fast forward. Even if 'pull' > failed somehow, if it is not reporting its failure, it is even > more worrysome. I don't recall ever having done anything at all in the dir that is being snapshotted. So the only thing that should be happening is the side-effects of the script. Here it is in its entirity.. DATE=`date +%Y-%m-%d` PROJ="git" cd ~/git-trees if [ -d $PROJ ]; then cd $PROJ git pull -n else git clone -q git://git.kernel.org/pub/scm/git/git.git cd $PROJ fi snap=git-snapshot-$(date +"%Y%m%d") git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz mv $PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/ rm -f ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-`date +%Y-%m-%d --date="7 days ago"`.tar.gz ln -sf ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-latest.tar.gz #git-fsck-objects --full I'll save that broken dir away somewhere, and rerun the script (which as you can see above will make it reclone from scratch). If you want a copy of the .git of the broken tree I can put that up somewhere too. Hmm, I just checked the mail cron sent out recently (sadly I don't have an archive of older mails). It does look a bit strange.. got 49be764e948668341034e121fad5cf07ab079bff got 415c09ba10a391cec60c939da1722c83df7cd906 * refs/heads/origin: fast forward to branch 'master' of http://www.kernel.org/pub/scm/git/git from 8a5dbef8ac24bc5a28409d646cf3ff6db0cccb3f to 38529e28a4f465ad5d5f2fa249ca17da680bac5f Failed to fetch refs/heads/gb/diffdelta from http://www.kernel.org/pub/scm/git/git.git Interesting. It looks like my original clone was over http. Another reason to reclone over git: I guess. Dave - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html