[feature] Added support for negative alt condition

[AaronYoung5]

What does this PR do?

Adds negative conditions to alt resolution. For instance, if local.class=test, file##!c.test is an invalid condition. This is useful for me where I want to disable a file on a specific computer.

What issues does this PR fix or reference?

I didn't make an issue, should I?

Previous Behavior

This is a new feature. Before, there was no way (that I know) to accomplish a negative condition.

New Behavior

See test case and comments below. Basically, it's possible to avoid using a specific file if a given condition is met if prefixed with !.

YADM_TEST=1 source {yadm}
score=0
local_class="testclass"
local_classes=("testclass")
# Negative condition with matching value should yield delta -1 and zero the score.
score_file "filename##!class.testclass" "dest"
echo "score: $score"
# Negative condition with non-matching value should yield delta 16.
score=0
score_file "filename##!class.badclass" "dest"
echo "score2: $score"

Have tests been written for this change?

Yes

Have these commits been signed with GnuPG?

No

---

Please review yadm's Contributing Guide for best practices.

[erijo]

Hi and thanks for your contribution! This has been requested before (see #365) and I would like to get this merged. But first a few things that would be good if you could look into:

• The logic could be simplified if we do something like this:

  local delta=
  case "$label" in
  ...
    a | arch)
      [[ "$value" = "$local_arch" ]] && delta=1 || delta=-1
      ;;
  ...
  esac
  if [ -z "$delta" ]; then
    score=0
    return
  fi
  (( negate )) && delta=(( -delta ))
  

• I'm wondering if it would be better to use .e.g not- instead of !. So that it would be e.g. ##not-class.foobar. What do you think?
• It would be good if you could add some documentation to yadm.1.

[AaronYoung5]

Thanks for the quick response!

1. Nice, much cleaner :)
2. I agree that ! isn't great, it's hard to see it sometimes in long file names. For not-, would short hands like not-c still be supported? What are your thoughts on ~ instead, so ~class.foobar and ~c.foobar?
3. I agree. I was also hoping to add exact scoring criteria in the docs (unless that's already there and I just missed it). My interpretation of the contributing doc is that all documentation changes are done in dev-pages, is that correct? Should that be a separate PR then?