--loop --changed-since does not behave entirely as expected.

[xlevus]

Describe the bug
When running --loop with --changed-since, pants does not re-compute changed targets on each iteration.

How to reproduce:

1. run ./pants --loop --changed-since=HEAD
2. Modify a file
3. nothing happens.
4. restart ./pants --loop --changed-since=HEAD
5. delete a file
6. Pants goes into an error-loop.

Pants version
2.8.0

OS
Linux

[stuhood]

Yea, this would be good to fix. We also shouldn't eagerly re-run in case of exceptions.

[stuhood]

There has been some interest in tackling this one recently, so here are some thoughts on how to do so (roughly organized as things which could be separate commits, some of which could be separate PRs):

1. Expose get_git as a @rule, and extend the Git return type of the @rule (or a wrapper around it) from EngineAwareReturnType, with an implementation of EngineAwareReturnType.cacheable which always returns False.
   • This will effectively fix Git state available during request #13724, although we should be careful about making it a public API.
2. Convert calculate_specs into a @rule, and convert its call to get_git into a Git (or wrapper type) argument to the calculate_specs @rule. Continue to call it as if it wasn't a @rule, but now by passing the Git argument explicitly.
   • BUT: Don't register it as a @rule yet in def rules in its file: doing so will cause graph ambiguity.
3. Register calculate_specs as a @rule in def rules, and adjust the signature that @goal_rules are invoked with to not take the Specs as an explicit argument. They'll be calculated implicitly from the OptionsBootstrapper instead.