From 8017a1acfaa4b810c94a3f173cdaab7771b80c8b Mon Sep 17 00:00:00 2001 From: "Kyle J. McKay" Date: Mon, 10 Aug 2020 14:00:01 -0700 Subject: [PATCH] jobd/gc.sh: ameliorate alarming combine-packs message The combine-packs.sh command may spew a message like this: combine-packs: fatal: missing 5 object(s) On the surface, that may seem quite alarming. However, in the case of the `make_needs_pack` function, it's possible that the incoming loose objects are not fully connected in which case the failure will be ignored and they will be packed later with `--weak-naming` which does not require full connectivity (at the expense of just-slightly larger packs). When the `make_needs_pack` function ends up ignoring a fatal combine-packs error, output another message to STDERR as a follow up mentioning that --weak-naming will be used instead to avoid unnecessary alarm over the combine-packs fatal message. While it would, indeed, be possible to send the combine-packs output (including STDERR) to /dev/null instead, that could potentially hide useful diagnostic information in the event of some other kind of fatal error that's not just about missing objects. That would be less than ideal, hence the new follow-up message instead. Additionally, the new follow-up message includes the project name to help identify the offending source of the misunderdisconnected [sic] objects. Signed-off-by: Kyle J. McKay --- jobd/gc.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/jobd/gc.sh b/jobd/gc.sh index 84f0c57..77c5118 100755 --- a/jobd/gc.sh +++ b/jobd/gc.sh @@ -280,6 +280,9 @@ make_needs_pack() { # .needspack behind to potentially continue to fail again and # again. _newp= + # combine-packs.sh will have output a nasty fatal message, + # ameliorate it with a follow up to say that all is okay + echo "gc: bad needs_pack connectivity, using --weak-naming: $proj" >&2 } if [ -n "$_newp" ]; then # remove the now-redundant loose objects -- this is always safe -- 2.11.4.GIT