I want to automatically copy files in a specific directory and stage the files once the user types in git commit.
I tried the pre-commit hook did the copying stuff and added git add .
However the stages don't affect the commit itself, I get the message, there is nothing to commit.
Is there a way to run a script, when the user runs git add so a staging hook?
Unfortunately there are no hook for git add action, but only the listed (client) hooks in the official documentation at https://git-scm.com/book/it/v2/Customizing-Git-Git-Hooks :
When you run git commit, Git is prepared to commit the files that are in Git's index. It is not going to commit the files that are in your working tree.
When you run git add, Git copies a working-tree file into Git's index. This ejects the old copy (if there was an old copy) and puts in the new one instead. The files that are in Git's index are in a special form, suitable for storing in a commit: these are compressed and—importantly since Git stores every file in every commit—pre-de-duplicated, so that if this copy of this file matches any copy of any file in any existing commit, it's already de-duplicated. (This means that the files that are in Git's index are useless to you. That's why you have a usable version of the same file in your working tree—at least, up until you change it.)
Now, if you run git add from a pre-commit hook, this can work, sometimes. But sometimes, there's more than one index. When there is more than one index—and it's hard for you, in a pre-commit hook, to detect this case—running git add is not going to do any good: it may affect the next index, or may affect a temporary index that will be thrown away. In any case, the result will be bad.
What this means is that unless you are steeped in the deeper magic of Git and can detect the special index cases, you should never use git add in a pre-commit hook. If you wish to run git add before committing, do that: run git add, then run git commit.
You could, for instance, write a script that does whatever you need done, then runs git add, then runs git commit. Run this script instead of git commit. That would be a much safer way to achieve what you are trying to achieve.
As Marek R suggested in a comment, this really does look like a case of an XY problem. As LeGEC answered and I suggested above, using a script seems like the way to solve the real problem.
From your comments : I have the feeling that you are doing something by hand (combining changes from two sources) for which git was specifically designed (git merge has already a whole lot of features).
For example : I wouldn't consider re-implementing file renames detection, or diff reconciliation. It would certainly have more bugs and be way less tested than git builtin features.
Do consider storing the two versions of that app in two branches of the same repo, and combine them using git merge.
It looks like you simply want to run a script :
./update-vendor-files.sh That script would use git, but, correct me if I'm wrong, I think it wouldn't be that cumbersome for a developer to know that he should run this specific action when he needs to, rather than trying to automatically trigger it on any git add or git commit action.
If you want a more gity way to call that script :
git-update-vendor-files,PATH,you can now run :
git update-vendor-files 
git commit. See this discussion, which seems to cover your case.