Yeah, was a false positive. Thanks, tho...
On May 7, 6:50 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> Hmm. You shouldn't need capistrano on any server but the one you are
> deploying from. I'm not sure installing it on the remote server(s)
> would have any effect at all...
>
> - Jamis
>
> On May 7, 2008, at 7:32 PM, BenHill wrote:
>
>
>
> > Hi, Folks.
>
> > Actually, chalk this up to my own stupidity. I hadn't upgraded
> > capistrano on the production server. I did that and everything is
> > working for me.
>
> > Ben
>
> > On May 6, 7:29 am, zmalltalker <[EMAIL PROTECTED]> wrote:
> >> The small patch
>
> >> execute << "#{git} fetch #{remote} && #{git} fetch --tags
> >> #{remote} && #{git} reset --hard #{revision}"
>
> >> worked like a charm for me, +1.
>
> >> Marius
>
> >> On May 6, 3:36 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
> >> wrote:
>
> >>> I added a note to ticket, waiting for reply from Alex
>
> >>> On Tue, May 6, 2008 at 3:22 PM, Patrick Lenz <[EMAIL PROTECTED]
> >>> overload.de>
> >>> wrote:
>
> >>>> Hi Jamis,
>
> >>>> basically you'd just need to reverse the patch in ticket #6,
> >>>> should I
> >>>> just reopen that one and attach a note?
>
> >>>> Best,
> >>>> Patrick
>
> >>>> On May 6, 2008, at 3:09 PM, Jamis Buck wrote:
>
> >>>>> 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/838f6abd74b4d4244111a698ab8
> >>>> ...
> >>>>>> [3]
> >>>>http://capistrano.lighthouseapp.com/projects/8716/tickets/6-git-modul
> >>>> ...
>
> >>>>>> 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
-~----------~----~----~----~------~----~------~--~---
