oradian/monohash

Fast hashing library designed to work with monorepos

monohash's Issues

Verification `require` should never write to an export file

If the export file exists and it was a mismatch - it will exit without touching it.
If the export file exists and it was a correct hash, there is no need to overwrite it :D

Make blacklist .gitignore compatible

There is no need to introduce yet another syntax when people are already aware of .gitignore flavor

This is a breaking change that will push the version to 1.x.x

Monohash fails to die if hashing plan file contains non-existing file/folder

If monohash plan file contains a file or a folder that does not exist on the disk it fails to fail, looping eternally in agony.

Repro steps:

Folder structure:

~/repro/
  + monohash.jar
  + .monohash.plan

Hash plan:

@./

# this guy causes monohash to eternally loop in agony
./some_nonexisting_file

Repro command:

# cd into ~/repro/
java -jar monohash.jar .monohash.plan

Expected:

• monohash should fail immediately

What happens:

java -jar monohash.jar .monohash.plan
[info] Using [hash plan file]: <path/to/.monohash.plan> ...
[error] Worker #7 experienced an exception, shutting down other workers ...
[info] Hashed 0 files with a total of 0 bytes in 1.004 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 2.006 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 3.002 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 4.002 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 5.002 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 6.002 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
[info] Hashed 0 files with a total of 0 bytes in 7.002 sec (average speed: 0 files/sec, 0.0 MB/sec) [stopping early due to errors]
...
onwards to infinity

Prioritise huge files early in hash plan execution

It makes no sense to start hashing large files towards the end of the hash plan execution since all other workers will be idling and streaming digests do not benefit from parallelism.

Support include directives

If a repo has a base set of directories/files that should be included in every hash plan, it would be great to be able to specify it once and pull it into another hash plan via an 'include directive'.

E.g. <include ../build/shared.monohash>

Allowing nested chaining of includes should greatly reduce repetition
Con: Reduces readability. User friendly logging during parsing should help with that.