All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Elijah Newren <newren@gmail.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH 2/3] git add: make -p/-i aware of sparse index
Date: Fri, 16 May 2025 08:54:10 -0400	[thread overview]
Message-ID: <bee620e4-1f45-4fff-a7d4-ecb5f99f4e0a@gmail.com> (raw)
In-Reply-To: <CABPp-BEmMaFQxE9NQgM8M=cgfBHY1p56vnBt7R4CfuiXnq++4Q@mail.gmail.com>

On 5/10/25 12:38 AM, Elijah Newren wrote:
> On Tue, May 6, 2025 at 5:55 PM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: Derrick Stolee <stolee@gmail.com>
>>
>> It is slow to expand a sparse index in-memory due to parsing of trees.
>> We aim to minimize that performance cost when possible. 'git add -p'
>> uses 'git apply' child processes to modify the index, but still there
>> are some expansions that occur.
> 
> still there are some expansions that occur...outside of those child
> processes?  Is that what you're trying to say, or was it something
> else?
> 
>> It turns out that control flows out of cmd_add() in the interactive
>> cases before the lines that confirm that the builtin is integrated with
>> the sparse index. We need to move that earlier to ensure it prevents a
>> full index expansion on read.
>>
>> Add more test cases that confirm that these interactive add options work
>> with the sparse index. One interesting aspect here is that the '-i'
>> option avoids expanding the sparse index when a sparse directory exists
>> on disk while the '-p' option does hit the ensure_full_index() method.
>> This leaves some room for improvement, but this case should be atypical
>> as users should remain within their sparse-checkout.
> 
> It's not clear whether this paragraph is talking about existing state
> (before the patch) or desired state (after the patch).  I think based
> on the context it's the former, but the last sentence sounds more like
> a future work direction that makes it very unclear, to me at least.

I'll try to rewrite to make this clearer.

>> +       # -p does expand when edits are outside sparse checkout.
>> +       test_write_lines y n y >in &&
>> +       ensure_expanded add -p <in &&
>> +
>> +       # but -i does not expand.
>> +       git -C sparse-index reset &&
>> +       test_write_lines u 2 3 "" q >in &&
>> +       ensure_not_expanded add -i <in
> 
> This has the same error as patch 1, in that you assume your reset
> above (which wasn't even a reset --hard) will re-sparsify the index.
> Since it doesn't, your test is misleading and only shows that when
> already expanded to include the files of interest it doesn't expand
> any further.  To re-sparsify your index before the `add -i` call,
> you'll need to do a `git reset --hard && git sparse-checkout reapply`
> and then recreate folder1/a with "new content" again...and then run
> your 'add -i' command.
Thanks. I didn't like that this was different. I appreciate your
expertise helping to clarify this issue.

Thanks,
-Stolee


  reply	other threads:[~2025-05-16 12:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  0:55 [PATCH 0/3] Integrate the sparse index with 'git apply' and 'git add -p/-i' Derrick Stolee via GitGitGadget
2025-05-07  0:55 ` [PATCH 1/3] apply: integrate with the sparse index Derrick Stolee via GitGitGadget
2025-05-10  3:18   ` Elijah Newren
2025-05-16 12:49     ` Derrick Stolee
2025-05-07  0:55 ` [PATCH 2/3] git add: make -p/-i aware of " Derrick Stolee via GitGitGadget
2025-05-10  4:38   ` Elijah Newren
2025-05-16 12:54     ` Derrick Stolee [this message]
2025-05-07  0:55 ` [PATCH 3/3] p2000: add performance test for 'git add -p' Derrick Stolee via GitGitGadget
2025-05-10  4:39   ` Elijah Newren
2025-05-08 18:26 ` [PATCH 0/3] Integrate the sparse index with 'git apply' and 'git add -p/-i' Junio C Hamano
2025-05-14 15:16 ` Phillip Wood
2025-05-16 13:28   ` Derrick Stolee
2025-05-20 15:07     ` phillip.wood123
2025-05-16 14:55 ` [PATCH v2 0/4] Integrate the sparse index with 'git apply' and interactive add, checkout, and reset Derrick Stolee via GitGitGadget
2025-05-16 14:55   ` [PATCH v2 1/4] apply: integrate with the sparse index Derrick Stolee via GitGitGadget
2025-05-16 14:55   ` [PATCH v2 2/4] git add: make -p/-i aware of " Derrick Stolee via GitGitGadget
2025-05-16 14:55   ` [PATCH v2 3/4] reset: integrate sparse index with --patch Derrick Stolee via GitGitGadget
2025-05-16 16:20     ` Elijah Newren
2025-05-16 14:55   ` [PATCH v2 4/4] p2000: add performance test for patch-mode commands Derrick Stolee via GitGitGadget
2025-05-16 15:32   ` [PATCH v2 0/4] Integrate the sparse index with 'git apply' and interactive add, checkout, and reset Elijah Newren
2025-05-16 16:35     ` Derrick Stolee
2025-05-16 18:55     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bee620e4-1f45-4fff-a7d4-ecb5f99f4e0a@gmail.com \
    --to=stolee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.