Sounds like the perfect amount of diagnostics for a well identified bug. Feel free to log a ticket specifying the correct behavior :-)
On Jun 13, 2011 6:06 PM, "Jason J. W. Williams" <
">
> wrote:
> 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