On Thursday, July 25, 2013 at 6:50 AM, Cassiano Leal wrote:
Indeed setting shallow_clone to false solves the problem. It this the best approach, though? And why is that, since the revision that I’m trying to deploy is much newer than whatever is on master?
It's probably the only thing you can do that doesn't involve patching chef. I'm not sure exactly how clone depth works in git, in particular how it handles branches other than master. Here's what the manual says:
--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are
only interested in the recent history of a large project with a long history, and would want to send in fixes as
patches.
There is a --branch option to clone:
--branch <name>, -b <name>
Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to
<name> branch instead. --branch can also take tags and treat them like detached HEAD. In a non-bare repository,
this is the branch that will be checked out.
If you'd like to investigate further, you can see whether using --depth and --branch together results in a usable repo. I did a quick check and it seems to work for branches and tags, so it might be possible to fix this problem by patching chef to use -b.