On Mon, Aug 22, 2022 at 11:26 AM Eric Sunshine via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > From: Eric Sunshine <sunshine@xxxxxxxxxxxxxx> > > Failures within `for` and `while` loops can go unnoticed if not detected > and signaled manually since the loop itself does not abort when a > contained command fails, nor will a failure necessarily be detected when > the loop finishes since the loop returns the exit code of the last > command it ran on the final iteration, which may not be the command > which failed. Therefore, detect and signal failures manually within > loops using the idiom `|| return 1` (or `|| exit 1` within subshells). > > Signed-off-by: Eric Sunshine <sunshine@xxxxxxxxxxxxxx> [...] > diff --git a/t/t6429-merge-sequence-rename-caching.sh b/t/t6429-merge-sequence-rename-caching.sh > index e1ce9199164..650b3cd14ff 100755 > --- a/t/t6429-merge-sequence-rename-caching.sh > +++ b/t/t6429-merge-sequence-rename-caching.sh > @@ -725,7 +725,7 @@ test_expect_success 'avoid assuming we detected renames' ' > mkdir unrelated && > for i in $(test_seq 1 10) > do > - >unrelated/$i > + >unrelated/$i || exit 1 > done && > test_seq 2 10 >numbers && > test_seq 12 20 >values && > -- > gitgitgadget That's not something I'm likely ever going to remember to think of as capable of failing and needing this special care. Is this a preliminary series before you send chainlint improvements that finds this kind of thing for us? Or did you notice this some other way? Change is fine, of course, I'm just curious how it was found (and how I can avoid adding more of these that you'll need to later fix up).
