Re: [PATCH v2 2/3] stash: remove unnecessary process forking

From: Elijah Newren <newren@gmail.com>
Date: Dec 2, 2020, 16:09 UTC
Message-ID: <CABPp-BGTkGO+19_AUrHFF4P8J8g_RnfbL6r4jHkxYvdE5_h8mw@mail.gmail.com>
In-Reply-To: <xmqqr1o9m8on.fsf@gitster.c.googlers.com>

On Tue, Dec 1, 2020 at 3:02 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> >     git diff-index --cached --name-only --diff-filter=A $CTREE >"$a"
> >     git read-tree --reset $CTREE
> >     git update-index --add --stdin <"$a"
> >     rm -f "$a"
>
> This is orthogonal to what this patch does, as this is supposed to
> be just bug-for-bug compatible rewrite.
>
> But I wonder if the above sequence, whether it is done as a series
> of plumbing invocations or subroutine calls, is a relic dating back
> in the days before i-t-a existed.  If we want to revert the changes
> to the index for working tree files for removed or modified ones, I
> do not offhand see a good reason why we would want to keep the
> contents to new paths---if i-t-a were available when the sequence
> was designed, I suspect we would just have added the path as i-t-a
> in order to keep track of the presence of the path but not
> necessarily the contents in it.

Yeah, I thought a little bit about the same thing, but wasn't sure if there was some other reason for the current behavior or if there was some workflow that might be relying upon it. Rather than investigate and try to switch it over to i-t-a (which could still be done later), I more narrowly focused this series at just doing the "make the changes be available in the working tree, but remove them from the index unless it'd make it untracked" more carefully.