Git commit while parallel process still has handle on file

I am using Git in an automated process to commit files to a repository. In one use-case a script is writing a file to the worktree, which is eventually picked up by the reoccurring 'commit' command.

I noticed that Git commits a blank file to the index/repo if a process is still accessing or modifying the file. I don't have insights when the script will start or finish with the writing process.

Does anyone can think of a solution to ignore a file that is still written to? I have this issue on Windows

Thanks!

(This is more a comment than an answer, but needs more room than would fit in a comment.)

The only thing special about Git here is that git commit does not use the copy of the file that is in your work-tree. Instead, it uses the copy of the file that is in Git's index. That copy was created or updated some time ago, when you (or some agent working on your behalf) ran git add.¹ So:

I noticed that Git commits a blank file to the index/repo if a process is still accessing or modifying the file.

... what is probably happening is that the git add is running before the process has finished working with the file. This is the same underlying problem of course, it's just that the steps needed for synchronization involve the writing program and the git add step, rather than the writing program and the git commit step.

Since Git itself does nothing special here, what you will need is some way to know that the writing process has finished writing and that no new writing process has begun writing. In general, this is independent of any file level locking: you want a commit to be a self-consistent snapshot across all files.

¹The exceptions to this rule occur with git commit --include, git commit --only, and git commit -a. But all of these work by creating a temporary index and using git add (or an internal equivalent) to add to the temporary index, then committing using the temporary index. So these exceptions aren't really exceptions: they still commit from the index, it's just that "the" index is now a temporary index, rather than the main index.