That script can be used to ensure that all commited V files are vfmt-ed,
i.e. it will run `v fmt -w ` on them before commiting them.
To use the script in your V project, you need to be in the main folder
of your project, then do the equivalent of:
```sh
cp /PATH/TO_YOUR/V/cmd/tools/git_pre_commit_hook.vsh .git/hooks/pre-commit
chmod 755 .git/hooks/pre-commit
```
Note: you can use this command:
`git config --bool --add hooks.stopCommitOfNonVfmtedVFiles true`
... to make it just *prevent* the commiting of unformatted .v files,
i.e. stop the commiting, if they are not, but *without modifying them*
automatically (you will then need to run `v fmt -w` on them manually).
Note 2: Git supports the option `--no-verify`, to temporarily disable all hooks.
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
