From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id B43411F45E for ; Wed, 12 Feb 2020 21:13:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729047AbgBLVN4 (ORCPT ); Wed, 12 Feb 2020 16:13:56 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:55246 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727420AbgBLVN4 (ORCPT ); Wed, 12 Feb 2020 16:13:56 -0500 Received: by mail-wm1-f67.google.com with SMTP id g1so3919701wmh.4 for ; Wed, 12 Feb 2020 13:13:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WTcXxM1vaVfK01MbrVTHucRbJ+esuSybn374X6KSGrQ=; b=YRxZLkNUMgsJDm/OYZiyt0z91DkN9ZqX1MY9YuVLMnckGE28Dl9wSW/s0laliGsrxm AhIHAgU/CKTvrlHBwZ8L5rngV6U0AlgnLwXgDX2R2S7dH/MlSZUR7t2bgtjmEyC1mr93 w/l6VLdaOEYloeYzdSbpj68gE31oYdxIa13ckz+RAlImn/hGrKQiN2ethRk4QpHeN0Sa yPMbGgXEMsdjD7kZ7KiBsM3sEOyhEvQFgz5cq5bheKNxnJCV6tRVh7oYXGY1QSBvQecp sAYxf6A3ANXus9p1B7+YX2w/eBM3EURe+IH3cz/uxIb1AZTzHmmEyCaoPNb9DexWhZ9A /flg== X-Gm-Message-State: APjAAAUKAPENuuFLNgvN8j9yfropJRD8UknQMUQS3JmRI5AZHtizotd9 sJGDTP4d1l5gu4iFTfq1GrAwy4buOzYm6P2peC35GsQ4 X-Google-Smtp-Source: APXvYqwI4ExlcbH9SRzYacDPZJ+UiObWUuvz7w0owDJmRNFcAMHFe1DdWYxj0tLNjXlp2qHzuLmjoseJ+N4ytBB7q4c= X-Received: by 2002:a05:600c:21c6:: with SMTP id x6mr994428wmj.177.1581542034297; Wed, 12 Feb 2020 13:13:54 -0800 (PST) MIME-Version: 1.0 References: <20200212202210.GC4364@syl.local> In-Reply-To: <20200212202210.GC4364@syl.local> From: Eric Sunshine Date: Wed, 12 Feb 2020 16:13:42 -0500 Message-ID: Subject: Re: [PATCH 1/5] object.c: get_max_object_index and get_indexed_object accept 'r' parameter To: Taylor Blau Cc: Parth Gala via GitGitGadget , Git List , Parth Gala Content-Type: text/plain; charset="UTF-8" Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Feb 12, 2020 at 3:22 PM Taylor Blau wrote: > On Wed, Feb 12, 2020 at 07:19:07PM +0000, Parth Gala via GitGitGadget wrote: > > diff --git a/builtin/fsck.c b/builtin/fsck.c > > @@ -375,6 +375,7 @@ static void check_object(struct object *obj) > > static void check_connectivity(void) > > { > > int i, max; > > + struct repository *r = the_repository; > > Is there a reason that you assign use/assign 'r' here? [...] > but I'm not sure that it's necessary here. Could you instead pass > 'the_repository' directly to the functions that now require it? One benefit of doing it this way is that future patches will be much less noisy which convert these callers to also work with any 'repository' object. For instance, after the current patch, we have: static void check_connectivity(void) { struct repository *r = the_repository; max = get_max_object_index(r); ... A future patch which converts check_connectivity() to work with any repository will then require very little change -- just adding an 'r' argument to the function declaration, and dropping the line which declares 'r': static void check_connectivity(struct repository *r) { max = get_max_object_index(r); ... So, I'm fine with this patch series' approach of declaring a variable 'r' like this.