In local development, we use watchman to create content-addressed incremental state. It's great because it allows us to use subscriptions and respond to the working directory changes.
In CI for similar needs, we use git index itself which entirely avoids walking the filesystem. Here we don't need subscriptions or to handle working directory changes.
Unfortunately we can't use these interchangeably because they work of different content hashes.
We get Map<content.sha1hex, FileInfo> from watchman
We get Map<GitObjectHash, FileInfo> from the git index git ls-tree -r <ref>
We'd like to be able use the same incremental state across both strategies.
This request is to introduce a additional field to watchman (content.githashhex?), very similar to the existing content.sha1hex but returning the files git object hash (sha1("blob " + filesize + "\0" + data)) rather than content.sha1hex (sha1(data)).
In local development, we use watchman to create content-addressed incremental state. It's great because it allows us to use subscriptions and respond to the working directory changes.
In CI for similar needs, we use git index itself which entirely avoids walking the filesystem. Here we don't need subscriptions or to handle working directory changes.
Unfortunately we can't use these interchangeably because they work of different content hashes. We get
Map<content.sha1hex, FileInfo>
from watchman We getMap<GitObjectHash, FileInfo>
from the git indexgit ls-tree -r <ref>
We'd like to be able use the same incremental state across both strategies.
This request is to introduce a additional field to watchman (
content.githashhex
?), very similar to the existingcontent.sha1hex
but returning the files git object hash (sha1("blob " + filesize + "\0" + data)
) rather thancontent.sha1hex
(sha1(data)
).Would you accept a contribution of this feature?