Processing a single file

[agasparovic-sabre]

Hi there, thanks for a great tool! We're using pre-commit (pre-commit.com) to run checks before committing to my company's repo, and I'd love to integrate protolock to validate and commit changed .proto files.

Pre-commit is set up to pass filenames (either one at a time or a list, depending on what the tool can support) of modified files matching a pattern (like .proto) to a particular command-line tool. So the first enhancement would be to support protolock commit <filename>.

The second enhancement is minor but would also be helpful - if there were an option to make protolock commit <filename> return a non-zero status when proto.lock is actually updated (optionally with a message like "Updated proto.lock"), that would allow pre-commit to abort a git commit so that the user can add the modified file.

Let me know if you need additional information or would like an example of how to configure!

[nilslice]

Hi @agasparovic-sabre, my apologies, but I am having some difficulty understanding the problem.

1. Does protolock commit break when passing an unused <filename> parameter?
2. Do you need to check proto compatibility on a file-by-file basis?
3. Does protolock status -uptodate satisfy the second enhancement you mention?

[agasparovic-sabre]

1. It doesn't break, but it doesn't do anything elther.
2. Yes, that's the idea - the Pre-Commit tool runs user-defined checks on files in a git commit (and can block the commit until the checks pass). So I'd like to:
   a. only protolock commit files in the git commit
   b. fail the commit if there's a validation error.
3. Oh thanks - that's helpful!

[agasparovic-sabre]

Hi @nilslice, I thought of another reason why it would be helpful to process a single file at a time - I have a large git repository I'd like to use this with (a monorepo, in fact), which we normally use with sparse checkouts. That means only a portion of the repo is actually locally downloaded at any point. But we'd like to have a proto.lock file in the root for the whole repo, which means we need to iteratively add new/changed files (and ignore ones not in the local checkout but in the proto.lock file).