After a bit of investigation I think this is indeed the cause. The
manpage for git-fetch[1] is a little ambiguous about this, but I think
it really does say that with the --tags option it will only fetch tags
whereas without that option it will fetch tags and regular revisions.
This change[2] went in as a patch provided by Alex Arnell on
Lighthouse, so he might want to speak up regarding his case where tags
were unavailable with the regular fetch mode. According to the manpage
git would not download tags that don't point to any branch heads being
tracked, so this might as well be a local configuration issue or issue
with the Git version he used (and I don't know which).
If that's not the case, git.rb line 187 could be changed to:
execute << "#{git} fetch #{remote} && #{git} fetch --tags
#{remote} && #{git} reset --hard #{revision}"
to be on the safe side by fetching both revisions and tags explicitly.
That does feel a little hard on the performance side though, so it's
worth investigating whether or not the --tags part is really necessary
for the general public.
Best,
Patrick
[1] http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
[2]
http://github.com/jamis/capistrano/commit/838f6abd74b4d4244111a698ab8b955fbe678cde
[3]
http://capistrano.lighthouseapp.com/projects/8716/tickets/6-git-module-doesn-t-always-fetch-tags#ticket-6-5
On May 6, 10:07 am, Patrick Lenz <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
