[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: Detecting pushes originating from shallow clones?
From: Owen Jacobson <ojacobson () heroku ! com>
Date: 2015-11-30 23:11:41
Message-ID: 5C8F7871-D25C-4DDD-9F15-8EB9DF1F3103 () heroku ! com
[Download RAW message or body]
Owen Jacobson <ojacobson@heroku.com> 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@pobox.com> 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@heroku.com: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@heroku.com> 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@pobox.com> 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
["signature.asc" (signature.asc)]
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWXNetAAoJEAnOjZoiyXdEv1AP/Rq2l355AscvHU75Z7GorjQJ
yZwRXCqC0YrJI7BppzQjWALKWI8dLRHqmhmkQYtQrADIeudGXyIcrrVNp/IKXqev
mXoB0mPdHQQ+5Xt0OWbSF1k0gbnL6AuFMMSlc/cgyhQmI0j7ADNaThg2FMdRqdjc
l0sGyPoRgVKXpg8w0JBcj/4X07hR05BR1whxR/EmeGoj2fMqNNMPveDHd44fvLbs
KRdazNSsIGJU4Z1lD6JsPWBByuirggVgq+3J6iBUDUanFKVHv0jGEynD4YY5Vyg0
W6iPiKi4EmgOq6qG+HrciJyB9ZPX7CULHiVMR2xUcMIOnVetJf+FI8in3T9c2CgV
c5abqxV2zu9yYYjJH8Iek1dF/YG0MfUQI3aB9SA/YPkyeVqn9MGnx3osqTvX8Ohk
/degVUWlO3xkMhIwLQUTKCZCHzGVX0e38NmefkDzCbtOpAYqO0z77b8CR3nM/2EL
v6yPGBqiHW4UM1i9GhoLJcVNXPtVNmhnShP14xcTAfU1F5OVH9dvY1Vacd94LE/x
EJlqZvOMW3G2O4a7TbRpTGo1x+XT3yLm0kFB6lq41TADqgsRP9rkeQv8OTbj/0I2
H9nhqChy3nbVPhQcQbTqMCjnuPHl1ocZLcP39I0AiPEPlncoSOJIN7ze5+wWcpq2
HHA9P9vGQGhqFuOwpPpr
=iyf8
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]