Indeed, "git push --tags" pushes only tags, so "git fetch --tags" may *fetch
* only tags. This hasn't occurred to me.
The --tags option isn't needed because Capistrano uses SHA1 IDs exclusively
on remote. It gets the ID from a local tag/branch name.
So, +1 for removing --tags.
2008/5/6 Patrick Lenz <[EMAIL PROTECTED]>:
>
> 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
-~----------~----~----~----~------~----~------~--~---
