P3 Description
When running the `git skara jcheck` command line tool, it seems like it can only over use the .jcheck/conf configuration file from the commit/rev it's currently checking. While that is the correct behavior when validating commits, it's not necessarily what the user needs when trying to validate changes to .jcheck/conf itself. Especially when trying to verify that current repository contents doesn't break a new configuration, which is generally a nice thing to do if you for example enable whitespace checking on new file types.
I would like to support the following usecases (if possible):
1. Run jcheck on a commit or a series of commits using the .jcheck/conf in the same commit. (what we do by default today).
2. Run jcheck on a commit or a series of commits using the .jcheck/conf in a different specified commit.
3. Run jcheck on a commit or a series of commits using the .jcheck/conf in my workspace.
4. Run jcheck on a commit or a series of commits using a config file that I point to directly, that may have any name.
5. Run jcheck on the diff in my current workspace, either --staged or not using the .jcheck/conf in my workspace.
I would like to support the following usecases (if possible):
1. Run jcheck on a commit or a series of commits using the .jcheck/conf in the same commit. (what we do by default today).
2. Run jcheck on a commit or a series of commits using the .jcheck/conf in a different specified commit.
3. Run jcheck on a commit or a series of commits using the .jcheck/conf in my workspace.
4. Run jcheck on a commit or a series of commits using a config file that I point to directly, that may have any name.
5. Run jcheck on the diff in my current workspace, either --staged or not using the .jcheck/conf in my workspace.
