- From: "Jason J. W. Williams" <
>
- To:
- Subject: [chef] Re: Re: Re: Re: Service restarts on every Chef check-in.
- Date: Mon, 13 Jun 2011 19:05:51 -0600
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=CLmtONVSUMjpPTE27b+Ef55p0aUsIB8t3TQJEuaoSU6Fg1NDFtIre1pjcDIkuHZfdI NyBC5NhITPMcJPzOwQEbJ7oKe3fHBxZa+gjVFpn4iLdq9Q1DHvoQq35EkTZFCIoabMIb Q+1szgPTqe7NvJN3g1cT1ANVrX5D8N0qy7WTI=
On Mon, Jun 13, 2011 at 6:50 PM, AJ Christensen
<
>
wrote:
>
Doesn't sync just track a remote reference?
>
>
Surely it would be obvious with debug logging. :-)
The culprit seems to be this line:
[Tue, 14 Jun 2011 00:43:32 +0000] DEBUG: git[/git/progname] current
revision: ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 target revision:
6174a2af6cd7bae0d516337de08edffad023850a
The revision is set to a tag (not a branch) called "3.0.3a".
Technically, since it's a Git annotated tag, it get's it's own object
hash: 6174a2af6cd7bae0d516337de08edffad023850a. However, the actual
commit revision's hash is ce24a6cc63aa39b2f5cc81539d7497a4a27fc563. So
when Chef checks it out the repo shows
ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 as the commit. Then on the
next Chef run, Chef doesn't understand that it shouldn't be comparing
the tag's ID to the most recent repo commit ID, because they'll always
be different. Only way around it seems to be to use lightweight tags,
but then you lose annotation messages etc on the tag.
-J
Archive powered by MHonArc 2.6.16.