git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: William Baker <williamtbakeremail@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	William Baker via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, stolee@gmail.com,
	Johannes.Schindelin@gmx.de, jeffhost@microsoft.com,
	William Baker <William.Baker@microsoft.com>
Subject: Re: [PATCH v3 1/1] fsmonitor: don't fill bitmap with entries to be removed
Date: Tue, 15 Oct 2019 12:07:39 -0700
Message-ID: <3d3b290c-bc15-4bd5-e0c0-1377c9ec3ff9@gmail.com> (raw)
In-Reply-To: <xmqq1rvig3fb.fsf@gitster-ct.c.googlers.com>

On 10/11/19 6:26 PM, Junio C Hamano wrote:
> "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).

> 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

      reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 19:49 [PATCH 0/1] " William Baker via GitGitGadget
2019-10-03 19:49 ` [PATCH 1/1] " William Baker via GitGitGadget
2019-10-03 23:36   ` Junio C Hamano
2019-10-07 18:10     ` William Baker
2019-10-03 21:08 ` [PATCH 0/1] " Johannes Schindelin
2019-10-03 23:17   ` Junio C Hamano
2019-10-09 21:00 ` [PATCH v2 " William Baker via GitGitGadget
2019-10-09 21:00   ` [PATCH v2 1/1] " William Baker via GitGitGadget
2019-10-10 11:07     ` SZEDER Gábor
2019-10-10 11:22       ` SZEDER Gábor
2019-10-11 16:38         ` William Baker
2019-10-10  1:56   ` [PATCH v2 0/1] " Junio C Hamano
2019-10-10 12:02     ` Johannes Schindelin
2019-10-11 20:11   ` [PATCH v3 " William Baker via GitGitGadget
2019-10-11 20:11     ` [PATCH v3 1/1] " William Baker via GitGitGadget
2019-10-12  1:26       ` Junio C Hamano
2019-10-15 19:07         ` William Baker [this message]

Reply instructions:

You may reply publically 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=3d3b290c-bc15-4bd5-e0c0-1377c9ec3ff9@gmail.com \
    --to=williamtbakeremail@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=William.Baker@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=jeffhost@microsoft.com \
    --cc=stolee@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

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git