Fair enough. I'm still new to git (and haven't needed to use git with
capistrano yet), so I'll rely on the experience of those who do in
this case. I'm traveling to Chicago today, returning Saturday, so my
time will be pretty thin. Is there anyone that would be able to put a
ticket for this up on lighthouse and possibly providing a patch?
- Jamis
On May 6, 2008, at 5:58 AM, Mislav Marohnić wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
