Owen Jacobson <ojacobson@xxxxxxxxxx> wrote:
> 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?
Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
It’s possible that that would fix the problem.
We do see pushes get rejected occasionally with output similar to
To git@xxxxxxxxxx:example.git
! [remote rejected] master -> master (missing necessary objects)
(We rely on customers reporting it to us, since right now we have no good way to spot this ourselves — we don’t get the output.)
However, this happens -after- the pre-receive and update hooks have already run. We’ve historically assumed that the hooks are the last step prior to accepting a push, so we assume that if the hook passes, then it’s safe to take side-effect-ful actions like deploying the newly-pushed branch tip to servers.
Git’s native error message also provides very little guidance on how users should resolve the problem. While I don’t think that’s Git’s responsibility in this case, it’d be nice to be able to insert our own messaging here, or to detect the problem earlier.
Owen Jacobson <ojacobson@xxxxxxxxxx> wrote:
> 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 …
Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
Hm. Well, if it’s essentially the same check, then perhaps running it ourselves in our hooks is the right fix.
Thanks for the input! I’m also interested in any other thoughts the list might have.
-o
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail