git/t/chainlint/chain-break-continue.expect

git ls-tree --name-only -r refs/notes/many_notes |
while read path
do
	test "$path" = "foobar/non-note.txt" && continue
	test "$path" = "deadbeef" && continue
	test "$path" = "de/adbeef" && continue

	if test $(expr length "$path") -ne $hexsz
	then
		return 1
	fi
done
chainlint.pl: don't require `return\|exit\|continue` to end with `&&` In order to check for &&-chain breakage, each time TestParser encounters a new command, it checks whether the previous command ends with `&&`, and -- with a couple exceptions -- signals breakage if it does not. The first exception is that a command may validly end with `\|\|`, which is commonly employed as `command \|\| return 1` at the very end of a loop body to terminate the loop early. The second is that piping one command's output with `\|` to another command does not constitute a &&-chain break (the exit status of the pipe is the exit status of the final command in the pipe). However, it turns out that there are a few additional cases found in the wild in which it is likely safe for `&&` to be missing even when other commands follow. For instance: while {condition-1} do test {condition-2} \|\| return 1 # or `exit 1` within a subshell more-commands done while {condition-1} do test {condition-2} \|\| continue more-commands done Such cases indicate deliberate thought about failure modes by the test author, thus flagging them as breaking the &&-chain is not helpful. Therefore, take these special cases into consideration when checking for &&-chain breakage. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2022-09-01 00:29:45 +00:00			`git ls-tree --name-only -r refs/notes/many_notes \|`
			`while read path`
			`do`
			`test "$path" = "foobar/non-note.txt" && continue`
			`test "$path" = "deadbeef" && continue`
			`test "$path" = "de/adbeef" && continue`

			`if test $(expr length "$path") -ne $hexsz`
			`then`
			`return 1`
			`fi`
			`done`