Re: [PATCH v2] fsmonitor: query watchman with right valid json

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 07 2022, Son Luong Ngoc wrote:

> In rare circumstances where the current git index does not carry the
> last_update_token, the fsmonitor v2 hook will be invoked with an
> empty string which would caused the final rendered json to be invalid.
>
>   ["query", "/path/to/my/git/repository/", {
>           "since": ,
>           "fields": ["name"],
>           "expression": ["not", ["dirname", ".git"]]
>   }]
>
> Which will left user with the following error message
>
>   > git status
>   failed to parse command from stdin: line 2, column 13, position 67: unexpected token near ','
>   Watchman: command returned no output.
>   Falling back to scanning...
>
> Hide the "since" field in json query when "last_update_token" is empty.
>
> Co-authored-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> Signed-off-by: Son Luong Ngoc <sluongng@xxxxxxxxx>

Thanks for the quick turnaround.

>  templates/hooks--fsmonitor-watchman.sample | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/templates/hooks--fsmonitor-watchman.sample b/templates/hooks--fsmonitor-watchman.sample
> index 14ed0aa42d..23e856f5de 100755
> --- a/templates/hooks--fsmonitor-watchman.sample
> +++ b/templates/hooks--fsmonitor-watchman.sample
> @@ -86,12 +86,13 @@ sub watchman_query {
>  	# recency index to select candidate nodes and "fields" to limit the
>  	# output to file names only. Then we're using the "expression" term to
>  	# further constrain the results.
> +	my $last_update_line = "";
>  	if (substr($last_update_token, 0, 1) eq "c") {
>  		$last_update_token = "\"$last_update_token\"";
> +		$last_update_line = qq[\n"since": $last_update_token,];
>  	}

This LGTM, just a note...

>  	my $query = <<"	END";
> -		["query", "$git_work_tree", {
> -			"since": $last_update_token,
> +		["query", "$git_work_tree", {$last_update_line

...doesn't really need a re-roll, but doesn't this trade "we don't have
too many \n" for not indenting the query properly anymore?

I think skipping both is fine, but between the two I think having
indenting is better than having a redundant \n some of the time.

FWIW you could just add the variable on its own line, and then do this
instead:

	(my $query = <<"        END") =~ s/(?<=\n)\t*\n//s; 

To post-hoc fix the extra \n in this case :)

But I think this is also fine as-is, thanks!




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux