RFR: 1690: Make jcheck cli able to use conf from workspace or other commit

[Erik Joelsson]

On Tue, 29 Nov 2022 18:24:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the command `git skara jcheck` can only use the `.jcheck/conf` configuration file in the current checking commit.
> However, sometimes users want to run jcheck with different configurations to validate their commits. Therefore, we need to upgrade `git skara jcheck`.
> 
> In this patch, `git skara jcheck` would be able to support following usecases.
> 
> 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)
> `git skara jcheck`
> 
> 2. Run jcheck on a commit or a series of commits using the .jcheck/conf in a different specified commit. 
> `git skara jcheck --specified-conf-commit <COMMIT HASH>`
> 
> 3. Run jcheck on a commit or a series of commits using the .jcheck/conf in my workspace. 
> `git skara jcheck --workspace-conf`
> 
> 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. 
> `git skara jcheck --workspace-conf --conf-file <FILENAME>`
> 
> 5. Run jcheck on the diff in my current workspace, either --staged or not using the .jcheck/conf in my workspace.
> `git skara jcheck --workspace-diff`

For 5, I think what we need is to create a "fake" Commit object based on the working-tree or staged content of a local repository. We could add methods like `ReadOnlyRepository::workingTree` and `::staged` that return `Commit` instances with the respective diffs, the current user as author, an empty commit message, and the current HEAD as parent.

In JCheck, we would need to define some special string constants that symbolize these special "commits". So if revisionRange has one of those values, JCheck would call one of these special methods instead of `ReadOnlyRepository::commits`. I would suggest values like `SKARA_GIT_WORKING_TREE_AS_REV` and `SKARA_GIT_STAGED_AS_REV`, something really long and unlikely to actually be a valid REV in any repository. I think these constants should stay in the jcheck module and not taint `GitRepository`, because there doesn't seem to be a standardized way of referring to the working tree as a "commit" in Git.

For Mercurial, I would just throw `UnsupportedOperationException`. It's not worth the time to implement this for Mercurial at this point.

-------------

PR: https://git.openjdk.org/skara/pull/1428