git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 1/1] fsmonitor: don't fill bitmap with entries to be removed

From
WBWilliam Baker <williamtbakeremail@gmail.com>
Date
Oct 15, 2019, 19:07 UTC
Message-ID
<3d3b290c-bc15-4bd5-e0c0-1377c9ec3ff9@gmail.com>
In-Reply-To
<xmqq1rvig3fb.fsf@gitster-ct.c.googlers.com>
On 10/11/19 6:26 PM, Junio C Hamano wrote:
Show 9 quoted lines
> "William Baker via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> +# Test staging/unstaging files that appear at the end of the index.  Test
>> +# file names begin with 'z' so that they are sorted to the end of the index. 
> 
> Well, the test is now done in a freshly created repository, so the
> z* files are the only thing you have in here---technically they are
> at the end of the index, but so they are at the beginning, too.
>

There is one other file in the index created by 'test_commit', however, the point still stands that there are almost no other entries in the index now that the test is using its own repository.

> Would it affect the effectiveness of the test that you do not have
> any other paths in the working tree or in the index, unlike the test
> in the previous rounds that did not use a newly created test
> repository?

The test still validates the scenario that we're concerned about, namely that the new index that's written has less entries than the index of the last entry in the old index that's is not flagged with CE_FSMONITOR_VALID but is flagged for removal (CE_REMOVE).

Show 8 quoted lines
> This is not a rhetorical question, but purely asking. "no, this
> still tests what we want to test and shows breakage when the fix to
> the code in the patch gets reverted" is perfectly a good answer, but
> in that case, is "the end of" the most important trait of the
> condition this test is checking?  Wouldn't the bug be exposed as
> long as we remove sufficiently large number of entries (like
> "removing more paths than the paths still in the index at the end"
> or something like that)?

This is exactly right. The most important trait is that the last entry flagged with CE_REMOVE does not have CE_FSMONITOR_VALID set and has an index >= the number of entries in the new index being written.

I will send out a patch on top of 'wb/fsmonitor-bitmap-fix' with an update to the comment for this test.

Thanks, William

Previous: Junio C Hamano
Message 17 of 17 in “fsmonitor: don't fill bitmap with entries to be removed”
  1. 0/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 3, 2019
  2. 1/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 3, 2019
  3. Junio C HamanoOct 3, 2019
  4. William BakerOct 7, 2019
  5. Johannes SchindelinOct 3, 2019
  6. Junio C HamanoOct 3, 2019
  7. 0/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 9, 2019
  8. 1/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 9, 2019
  9. SZEDER GáborOct 10, 2019
  10. SZEDER GáborOct 10, 2019
  11. William BakerOct 11, 2019
  12. Junio C HamanoOct 10, 2019
  13. Johannes SchindelinOct 10, 2019
  14. 0/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 11, 2019
  15. 1/1 fsmonitor: don't fill bitmap with entries to be removedWilliam Baker via GitGitGadget, Oct 11, 2019
  16. Junio C HamanoOct 12, 2019
  17. William BakerOct 15, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.