Owen Jacobson <ojacobson@xxxxxxxxxx> writes: > Hi folks, > > Here at Heroku, we ingest code from users by supplying them with a > Git server they can `git push` into. Occasionally, users will > attempt to push to us from a shallow clone, which causes numerous > problems for us and, often, for our users (incomplete > repositories, gaps in history, failed builds, and a host of other > problems). We’ve been investigating what we can do to give these > users clearer advice on how to fix the problem. > > Within the constraints that > > * we cannot control which version of Git our users have installed, and > * we run Git v1.9.1, obtained from the Ubuntu 14.04 LTS .deb repositories > > what can we do in an update/pre-receive hook to detect that an > incoming push originates from a shallow repository and reject it? Hmm, I would have suggested to set receive.fsckObjects which has been around since early 2008 (it is in v1.5.6, so it would likely be in v1.9.1 as well). But even without that configuration set, "push" shouldn't leave the receiving repository in an inconsistent state (e.g. incomplete repository, gaps in history) in the first place. Does anybody recall us having such a bug in the distant past in 1.9.1 and fixing it? I do not offhand recall but I wouldn't be surprised. > Right now, the best strategy we have is to observe whether > > git rev-list OLD NEW > > fails, and if it does fail, whether the stderr output includes the > phrase "revision walk setup failed”. This feels like a fairly > weak fix ... Actually, that (with "--objects" option) is essentially the test the receiving end does internally to detect the "gaps in history" when receive.fsckObjects configuration is set. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html