Actually I think this is related to git fetch --tags being used now
which apparently *only* fetches tags as opposed to fetching all commit
objects in addition to tags when a successive deploy is made.
Here's what's happening on my server:
if [ -d /APPROOT/shared/cached-copy ]; then
cd APPROOT/shared/cached-copy &&
git fetch --tags origin &&
git reset --hard 4777556990b3b6ce51a0452234886bda9dff8e00;
else
git clone GITREPO APPROOT/shared/cached-copy &&
cd APPROOT/shared/cached-copy &&
git checkout -b deploy 4777556990b3b6ce51a0452234886bda9dff8e00;
fi
So what's happening is that on a successive deploy git reset doesn't
have access to the newer revision present at the origin repository as
git fetch fails to retrieve these new revisions when invoked with the
--tags option. Dropping that option (or manually executing that
command on the server) works fine. I'm sure this went in for a reason
so it'd be pointless to now drop it completely.
Jamis?
On May 5, 8:16 pm, "Mislav Marohnić" <
mislav.maroh...@gmail.com>
wrote:
> Can you observe the output and find the git command that triggered this
> error?
>
> There is probably a problem with query_revision, but the error itself didn't
> come from Capistrano.
>