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ć" <[EMAIL PROTECTED]>
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.
>
> On Mon, May 5, 2008 at 1:33 AM, BenHill <[EMAIL PROTECTED]> wrote:
>
> > After deploying 2.3, I suddenly get this error when deploying:
>
> > "Needed a single revision"
>
> > ..the problem goes away when I roll back to 2.2.
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
