Fix flakey t7519.15 #197
Assignees
Labels
bug
Something isn't working
Comments
|
FYI @avar |
This was referenced May 23, 2019
Closed
dscho
added a commit
to dscho/git
that referenced
this issue
May 25, 2019
…-gfw Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 25, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 25, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 25, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 25, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 25, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 26, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
May 29, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git
that referenced
this issue
May 31, 2019
…-gfw Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
to git-for-windows/git
that referenced
this issue
Jun 3, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 3, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 3, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 4, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 8, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
to git-for-windows/git
that referenced
this issue
Jun 8, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 8, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/git
that referenced
this issue
Jun 21, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
to git-for-windows/git
that referenced
this issue
Jul 8, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
to git-for-windows/git
that referenced
this issue
Jul 11, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
to git-for-windows/git
that referenced
this issue
Jul 23, 2019
Fix racy fsmonitor The `t7519-status-fsmonitor.sh` tests became a *lot* more flaky with the recent fsmonitor fix (`js/fsmonitor-refresh-after-discarding-index`). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit *only* on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the `has_racy_timestamp()` test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes gitgitgadget#197 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
fsmonitorfeature is apparently not quite robust, or at least the mentioned test case isn't (see e.g. https://dev.azure.com/gitgitgadget/git/_build/results?buildId=9064&view=ms.vss-test-web.build-test-results-tab&runId=19542&resultId=101590&paneView=debug).The text was updated successfully, but these errors were encountered: