From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Beller Subject: Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail Date: Tue, 17 Nov 2015 12:49:37 -0800 Message-ID: References: <1447321061-74381-1-git-send-email-larsxschneider@gmail.com> <20151113053547.GD29708@sigill.intra.peff.net> <20151113233807.GD16173@sigill.intra.peff.net> <20151113234116.GA18234@sigill.intra.peff.net> <564A279C.6000802@web.de> <564A4DB1.4070507@web.de> <564B8406.9070706@web.de> <564B9091.7070902@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Jeff King , Lars Schneider , "git@vger.kernel.org" , Junio C Hamano , Duy Nguyen To: Jens Lehmann X-From: git-owner@vger.kernel.org Tue Nov 17 21:49:45 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZynCB-0006z0-Vi for gcvg-git-2@plane.gmane.org; Tue, 17 Nov 2015 21:49:44 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754009AbbKQUti (ORCPT ); Tue, 17 Nov 2015 15:49:38 -0500 Received: from mail-yk0-f182.google.com ([209.85.160.182]:33489 "EHLO mail-yk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009AbbKQUti (ORCPT ); Tue, 17 Nov 2015 15:49:38 -0500 Received: by ykdv3 with SMTP id v3so28405043ykd.0 for ; Tue, 17 Nov 2015 12:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k+Pi2kECSjugEVmSoRoysqM91f2cm6zT71ddBPgoTzc=; b=mCcF5Gce91F80VqPB6hZjUh6I3IAHHbmH7MPyco9dr7xqp6Q/Y3GhzjMo6v9HH9kNA oTkLVZuPwiwYfXBBVp34qzffz40FYdMgTDt6q2vLLGry2TLMrMpMt6qqD9a1SsbXfoJS 7KxmUktsssR4KnIxDTvtQfOHZFypmyoEdQ4dEst3wkpJrGGvzxcBsDmRjNYA1yjVZygj RhSkTUOPBIHgHzdOgARJ7eUkn4ro2BnA3hnRWtY8BQJn63IJ2tIXgvyBZN7ebsDVl1yP pIjqKi5Dmw1TOoIKflXphpXNfBKPhasMRoMQfgN1GNn50ApjEQY2cvRWMZnlVArR0gwL w8dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k+Pi2kECSjugEVmSoRoysqM91f2cm6zT71ddBPgoTzc=; b=TAnn2dLKmc2ZJX0pyz7g9EgwDcCtinbN69mt9uUA6PlKYZK0/5bRj9bfsMyUyqKpQ0 cHdVWJV9U7UwQ4k+u/Ll3HxjvopZ/QtRNyQvEhgkNoeAO95A7dgnaxjHZQhqPkpK1W5/ xP5DUSYFtK4Y47ZY0ZGxY1vOaMctwkGzP85jFqVwmCoHNP59jRnjbVfUq274otOgxa5w 8HK++lXJEZVufLA8lQLoKw+AWD2SHge15aOtxOS5YAR2ndpr5Fc8FZ9UG0Uh9LVbru30 0rmrpoEyaL2Uak3DrqHiS4/d0bLfDvpsbmAD73+Bkq3GSceNeSstedkzU1rnctKwyqCU lrGA== X-Gm-Message-State: ALoCoQmFEa3qSwlLv4l5XPpMMCFR/0gXiX3mNA/nbg0lmO7Cnknumo78pOWhX27EBeOwJ8nbtPuO X-Received: by 10.13.214.19 with SMTP id y19mr43711626ywd.63.1447793377255; Tue, 17 Nov 2015 12:49:37 -0800 (PST) Received: by 10.37.196.70 with HTTP; Tue, 17 Nov 2015 12:49:37 -0800 (PST) In-Reply-To: <564B9091.7070902@web.de> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Tue, Nov 17, 2015 at 12:39 PM, Jens Lehmann wrote: > Am 17.11.2015 um 21:04 schrieb Stefan Beller: >> >> On Tue, Nov 17, 2015 at 11:46 AM, Jens Lehmann >> wrote: >>> >>> >>> But for quite some time you'll have older servers out there that >>> don't support fetching a single sha1 or aren't configured to do so. >> >> >> Only when talking about the open source side. If you have all the >> submodules/superprojects on your companies mirror, you can control >> the git installations there. > > > Sure. But that doesn't mean we should make life harder for the open > source side, no? We'll have to support both for quite some time. > >>> Wouldn't it be better to give the user an appropriate warning and >>> fall back to cloning everything for those submodules while using the >>> optimized new method for all others and the superproject? Otherwise >>> you won't be able to limit the depth if only a single submodule >>> server doesn't support fetching a single sha1. >>> >> >> I think warnings are fine, but no fallbacks. The warning could look like: >> >> Server for submodule doesn't support fetching by sha1. >> Fetch again without depth argument. >> >> and keep going with the other submodules. This would allow the user >> to make an informed decision if they want to have the fallback solution >> (which requires more band width, disk space) > > > No, this is a regression. This worked before but now some submodules > are missing from the clone. And if that happens inside a Jenkins > script I doubt that Jenkins can make an informed decision, that job > will simply fail. > >> On the other hand, that's what people do today, so it's not that bad >> either, >> so I guess falling bad would work too. > > > Not that bad? I don't see any other sane way. Don't break formerly > working use cases without a very good reason. Fall back to what we > did before (even if it is suboptimal) and only then use the new > optimized (and admittedly better) feature when it is available. I assumed we'd have yet another flag to activate the new behavior, but if you want to roll out that new feature as a default, I agree on needing the fallback.