From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-6.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 582B32070F for ; Mon, 19 Sep 2016 20:11:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbcISULy (ORCPT ); Mon, 19 Sep 2016 16:11:54 -0400 Received: from smtprelay04.ispgateway.de ([80.67.31.27]:40308 "EHLO smtprelay04.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbcISULx (ORCPT ); Mon, 19 Sep 2016 16:11:53 -0400 Received: from [84.168.70.3] (helo=book.hvoigt.net) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bm4rk-0004rv-Gp; Mon, 19 Sep 2016 22:08:36 +0200 Date: Mon, 19 Sep 2016 22:08:35 +0200 From: Heiko Voigt To: Junio C Hamano Cc: Jeff King , Stefan Beller , "git@vger.kernel.org" , Jens Lehmann , Fredrik Gustafsson , Leandro Lucarella Subject: Re: [PATCH 3/2] batch check whether submodule needs pushing into one call Message-ID: <20160919200835.GD62429@book.hvoigt.net> References: <20160824230115.jhmcr4r7wobj5ejb@sigill.intra.peff.net> <20160914173124.GA7613@sandbox> <20160915121044.GA96648@book.hvoigt.net> <20160916094019.GB1488@book.hvoigt.net> <20160916123155.GA40725@book.hvoigt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Df-Sender: aHZvaWd0QGh2b2lndC5uZXQ= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Sep 16, 2016 at 11:13:09AM -0700, Junio C Hamano wrote: > Heiko Voigt writes: > > The most exact solution would be to use all actual remote refs available > > (not sure if we have them at this point in the process?) another > > solution would be to still append the --remotes= option as a > > fallback to reduce the revisions. > > I'd say --remotes= is the least problematic thing to do. Ok then lets drop my last patch and keep it the way it was. Because if the remote sha1 differs we probably do not have it locally anyway. The only case this does not catch is when the user specifies a remote URL. But that just means we will iterate over all revisions instead of a reduced set, which makes the check slower but still correct. As one can see from my measurements that should not be that bad anymore. Cheers Heiko