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