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-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 6B0681F5AE for ; Mon, 15 Jun 2020 12:02:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729732AbgFOMCe (ORCPT ); Mon, 15 Jun 2020 08:02:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729685AbgFOMCe (ORCPT ); Mon, 15 Jun 2020 08:02:34 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1765FC061A0E for ; Mon, 15 Jun 2020 05:02:33 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id gl26so17095819ejb.11 for ; Mon, 15 Jun 2020 05:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PiMLhnGOUXicoKRZ1k0wreuAnulWjWJg2uPDUQONRck=; b=X6h+zATKCp1xfa4wTlenWhTnPkKCmxl4jHW9WzU2M+R9EAWjqnh38YPzH6Bt2m+D5G hnDMAavz7+EVBZn/CLGPqTPrHB7SfaLvGs5qqKfK94sGWPJ9KSxS8Pz6eCCt3on0Tr8F nmi8dnpuDh9vtGGw8TW9zEufu8UqptLhWcGCMmwf5/h1x9dhtKvYalE2cHNrvsT9toUN 41qcW2j+V11iwgmngojMzwnmZbGLZ3t0/yqoPK6x48cPuvqmkxHmWGBSu4H4rVUg5FOM BMIUz4VUWTqjQEiSNga+i/pGY4D4hlPnJiThQMBj8K18ifEdIpCgVqGA/oAsLUBUFgUp LAeA== 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:content-transfer-encoding; bh=PiMLhnGOUXicoKRZ1k0wreuAnulWjWJg2uPDUQONRck=; b=Z7lSNCtBuFhVyhZXegLGqKLFxOcY09a24I8lf/El1UOGleSAAiGGBqTNh6cVY/RMd7 PFCZOPdkognlqTa89nhyUrh38wgrIgNsOoDrxsj9rns3gzjvzhwL71SaLy1DJMcQWxfr Moogb4YWnUEBFFF4C3uhvPnQNJ4ZPoRvbDsSmGK6BheI78WdVb4r/kixGyfEXJC4oFez 4TlZt7lF+1g1j0/pPTdB44eKNfyG/PJjfgmMTcimzhqRGJvpg28VL311xm7mOq1weJUZ TeMrhMKT1F37d9096WtvhLaYzJ8vcplas2qol0SkBpbB32aJjfcrBbrOrf+MsiZKNLRR S5vQ== X-Gm-Message-State: AOAM530M2TxXLgegA7qXDT9mc34ouEI2Si0NgXRNqc7A/t7jMzyHU3Mg TXIF6HOQxeYhalhiO4WwkqhIFAJuTfG60teeo+g= X-Google-Smtp-Source: ABdhPJwGpBvRMnCbtUKz8SDuVtDMggJoRZhN34sG0B2AuSTSlPfEPlY0sJz5lklErWDWVn3XdZumNBcOCZVz03TKoro= X-Received: by 2002:a17:907:685:: with SMTP id wn5mr26633147ejb.283.1592222551748; Mon, 15 Jun 2020 05:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20200505104849.13602-1-alban.gruin@gmail.com> <20200505104849.13602-3-alban.gruin@gmail.com> <2158eec0-9332-fe10-3636-95550a66f05d@gmail.com> In-Reply-To: <2158eec0-9332-fe10-3636-95550a66f05d@gmail.com> From: Christian Couder Date: Mon, 15 Jun 2020 14:02:19 +0200 Message-ID: Subject: Re: [RFC PATCH v1 2/6] stash: remove the second index in stash_working_tree() To: Alban Gruin Cc: git , Thomas Gummerer , Johannes Schindelin , Junio C Hamano Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sat, Jun 13, 2020 at 8:00 PM Alban Gruin wrote: > > Le 13/06/2020 =C3=A0 10:52, Christian Couder a =C3=A9crit : > > On Tue, May 5, 2020 at 12:56 PM Alban Gruin wro= te: > >> The call to reset_tree() becomes useless: > > > > Your patch doesn't remove any call to reset_tree(), but actually adds > > one. So the above is difficult to understand. > > > > Do you want to say that in a later patch it will be possible to remove > > the call to reset_tree()? Or do you want to say that the call to > > write_index_as_tree() becomes useless? > > > > No, I meant that with this commit, reset_tree() does not need to be > called at the beginning of stash_working_tree(), because it is only > called by do_create_stash(), which sets the index at `i_tree', and > save_untracked_files() does not change the main index. But it will > become useful again down the line, when save_untracked_file() will be > rewritten to use the "main" index, so I did not remove it. > > I hope it makes more sense now. Yeah, it makes more sense with an explanation like the above. Instead of "down the line" though, you might want to say something like "in a later commit", as I think it will make it clearer for reviewers that the commit when it will become useful again should be part of the same series. Thanks, Christian.