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

Re: [PATCH 3/6] fsmonitor: Update helper tool, now that flags are filled later

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 4, 2018, 23:03 UTC
Message-ID
<alpine.DEB.2.21.1.1801042348500.32@MININT-6BKU6QN.europe.corp.microsoft.com>
In-Reply-To
<fb10a998d5a8250f26d3504a1d1f5ca6723160d7.1514948078.git.alexmv@dropbox.com>
Hi Alex,
On Tue, 2 Jan 2018, Alex Vandiver wrote:
Show 17 quoted lines
> diff --git a/config.c b/config.c
> index e617c2018..7c6ed888e 100644
> --- a/config.c
> +++ b/config.c
> @@ -2174,8 +2174,13 @@ int git_config_get_fsmonitor(void)
>  	if (core_fsmonitor && !*core_fsmonitor)
>  		core_fsmonitor = NULL;
>  
> -	if (core_fsmonitor)
> -		return 1;
> +
> +	if (core_fsmonitor) {
> +		if (!strcasecmp(core_fsmonitor, "keep"))
> +			return -1;
> +		else
> +			return 1;
> +	}
It took me a while to reason about this:
- there is no existing code path that can return -1 from
  git_config_get_fsmonitor(),
- the callers in builtin/update-index.c (testing explicitly for 0 and 1)
  do not matter because they only trigger warnings.
- the remaining two callers are in fsmonitor.c:
  - tweak_fsmonitor() (which handles -1 specifically), and
  - inflate_fsmonitor_ewah(), which only tests whether
    git_config_get_fsmonitor() returned a non-zero value, but that test is
    inside a code block that is only triggered if the index has an
    fsmonitor_dirty array, meaning: it already had fsmonitor enabled.
    Therefore the test is legitimate.

This would take the next reader as much time, I would wager a bet. So maybe you can include this information (or at least the information about inflate_fsmonitor_ewah()) in the commit message?

Show 14 quoted lines
> diff --git a/t/helper/test-dump-fsmonitor.c b/t/helper/test-dump-fsmonitor.c
> index ad452707e..48c4bab0b 100644
> --- a/t/helper/test-dump-fsmonitor.c
> +++ b/t/helper/test-dump-fsmonitor.c
> @@ -1,12 +1,14 @@
>  #include "cache.h"
> +#include "config.h"
>  
>  int cmd_main(int ac, const char **av)
>  {
>  	struct index_state *istate = &the_index;
>  	int i;
>  
> +	git_config_push_parameter("core.fsmonitor=keep");

The alternative would be to use an environment variable. We already use GIT_FSMONITOR_TEST.

However, I wonder why we need this. Do we really update the index anywhere in the tests, then *toggle* the core.fsmonitor setting, and *then* call test-dump-fsmonitor?

And if we do, can't we simply avoid it?

Ciao, Johannes

Previous: Alex Vandiver
Message 15 of 15 in “Minor fsmonitor bugfixes, use with `git diff`”
  1. 0/6 Minor fsmonitor bugfixes, use with `git diff`Alex Vandiver, Jan 3, 2018
  2. 1/6 Fix comments to agree with argument nameAlex Vandiver, Jan 3, 2018
  3. 6/6 fsmonitor: Use fsmonitor data in `git diff`Alex Vandiver, Jan 3, 2018
  4. Johannes SchindelinJan 4, 2018
  5. Junio C HamanoJan 5, 2018
  6. Ben PeartJan 8, 2018
  7. 5/6 fsmonitor: Remove debugging lines from t/t7519-status-fsmonitor.shAlex Vandiver, Jan 3, 2018
  8. 2/6 fsmonitor: Stop inline'ing mark_fsmonitor_valid / _invalidAlex Vandiver, Jan 3, 2018
  9. Johannes SchindelinJan 4, 2018
  10. Ben PeartJan 8, 2018
  11. 4/6 fsmonitor: Make output of test-dump-fsmonitor more conciseAlex Vandiver, Jan 3, 2018
  12. Johannes SchindelinJan 4, 2018
  13. Ben PeartJan 8, 2018
  14. 3/6 fsmonitor: Update helper tool, now that flags are filled laterAlex Vandiver, Jan 3, 2018
  15. Johannes SchindelinJan 4, 2018

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.