Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> Dumb commit walker does not care about .git/shallow and until someone
> steps up to make it happen, let's not publish shallow clones using
> dumb protocols.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---
> server-info.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
I doubt that pros-and-cons is in this patch's favor. Without this
patch, if a fetch requests commits just on the surface in this
shallow repository, the walker would happily get the necessary
objects just fine. If the request has to dig deeper and cross the
shallow boundary, the walker will get a failure and error out.
With this patch, both will error out. So overall, the patch did not
make anything safer (e.g. preventing from introducing new corruption
on the recipient's end) while breaking a case where it worked just
fine, no?
Or am I missing something? Not that dumb walkers would matter very
much these days, ...
> diff --git a/server-info.c b/server-info.c
> index 9ec744e..a8df6a5 100644
> --- a/server-info.c
> +++ b/server-info.c
> @@ -33,6 +33,10 @@ static int update_info_refs(int force)
> strcpy(path1 + len, "+");
>
> safe_create_leading_directories(path0);
> + if (is_repository_shallow()) {
> + unlink(path0);
> + return error("info/refs not updated for shallow clone");
> + }
> info_ref_fp = fopen(path1, "w");
> if (!info_ref_fp)
> return error("unable to update %s", path1);
> @@ -217,6 +221,11 @@ static int update_info_packs(int force)
> strcpy(name, infofile);
> strcpy(name + namelen, "+");
>
> + if (is_repository_shallow()) {
> + unlink(infofile);
> + return error("info/packs not updated for shallow clone");
> + }
> +
> init_pack_info(infofile, force);
>
> safe_create_leading_directories(name);
--
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