Check if lockfile is up to date about protolock

[nilslice]

That sounds pretty reasonable to me. How do you anticipate the output from running this to look?

Based on the desired output, maybe it should be the default when executing status... especially since the tool can't do it's job if you're not locking the inputs.

Printing a single warning message and exiting abnormally should be enough - showing a diff or reporting on the changes would probably be too noisy.

Having it as the default would be nice, though perhaps a breaking change? It might then also be convenient to set the status code differently if the lockfile is just out-of-date, so build/test system integrations can distinguish between the two.

[nilslice]

Printing a single warning message and exiting abnormally should be enough

100% agree!

Having it as the default would be nice, though perhaps a breaking change? It might then also be convenient to set the status code differently if the lockfile is just out-of-date, so build/test system integrations can distinguish between the two.

I also agree with you here... maybe we can include it as a default, but choose to return a non-zero exit code only if some configuration flag is set? This way, it's not a breaking change, but can be included as a default so it is useful to all users right away. I'm not sold either way yet -- please let me know what you think based on what is optimally useful.

This might also be a good time to re-visit @sidtaduri's #86.

The flag sounds best. It looks like the CLI parsing would need a little refactoring, as currently all flags apply to all subcommands.

---

If this all sounds good, I have some bandwidth to implement this.

[nilslice]

Ok, great -- yea if you want to go ahead, please do!

I believe the flag parsing can stay more-or-less the same, but the config struct should use a good "zero value" for the new flag, and used in the same way the other configuration flags are:
https://github.com/nilslice/protolock/blob/master/cmd/protolock/main.go#L62

This way it should simplify the eventual use of a config file and how it is parsed and applied.

Let me know if you find otherwise though! Thanks

[nilslice]

added in #109 (from #102)