On Thu, Sep 14, 2006 at 12:15:03PM -0700, Junio C Hamano wrote:
> Dave Jones <davej@redhat.com> 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
