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