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]>
> > 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
-~----------~----~----~----~------~----~------~--~---
