I have a GIT backup script that runs perfectly when executed from command line (it's a daily backup of our main GIT rep):
@echo off
rem -- Set Parameters
rem -- daliy GIT backup
REM Get DATE
set mm=%Date:~4,2%
set dd=%Date:~7,2%
set yy=%Date:~10,4%
set TODAY=%yy%%mm%%dd%
for /f %%a in ('date /t') do set DAY=%%a
if %DAY%==Sun goto :weekend
if %DAY%==Sat goto :weekend
goto :weekday
:weekend
:: No backup after weekends
echo %day%
exit
:weekday
:: Backup during weekdays
REM Connect to share
REM net use z: \\backupnas\backup\
Z:
cd \
cd git
REM Start backup of current GITS
cd OptiTexRepo.git
call git fetch
cd ..
RAR.exe a -rr10 -s ARCHIVES\%TODAY%.OptiTexRep.git.rar OptiTexRepo.git
cd OptiTexRepo_V11.1.git
call git fetch
cd ..
RAR.exe a -rr10 -s ARCHIVES\%TODAY%.OptiTexRepo_V11.1.git.rar OptiTexRepo_V11.1.git
REM exit
However, when I run it as a scheduled task from a W2008R2 server, on a daily basis, it immediately exists (very similar to question https://serverfault.com/questions/343496/powershell-script-works-from-command-line-not-from-task-scheduler-why)
That gave me an idea, to check weather GIT FETCH works correctly with UNC - apparently it does, but when running in a task - something is wrong - and I can't figure what.
According to question: git on UNC path git should work, but I don't understand what needs to be the script command in order for it to actually work.
Currently I map my backup drive to Z:, and when I CD to the folder, I simply GIT FETCH (that reads from the config file where the master is)
How can I do that with using UNC? that will also work from the task scheduler?
Or is the problem actually somewhere else?
Git does work with UNC paths but typically it is more reliable to use them as Unixy paths - so git clone //backupnas/backup/repo.git for instance.
When running as a task - check that the permissions will allow your task to see the remote path with read access. Other than that - lots of echo's in the script and test the result codes for running commands. For the most recent version of msysGit you may not require the 'call git' anymore as the wrapper git.cmd got changed to a git.exe to resolve some quoting problems with ^ characters.
With Git 2.24 (Q4 2019), you can specify explicitly the UNC path with the file:// protocol.
That fixes git-for-windows/git issue 1264, where using such an URL failed:
$ git clone file://server/file/path/here
Cloning into 'here'...
fatal: 'C:/Program Files/Git/file/path/here' does not appear to be a git repository
fatal: Could not read from remote repository.
See commit ebb8d2c (24 Aug 2019) by Torsten Bögershausen (tboegi).
(Merged by Junio C Hamano -- gitster -- in commit aadac06, 30 Sep 2019)
mingw: support UNC in git clone file://server/share/repo
Extend the parser to accept file://server/share/repo in the way that Windows users expect it to be parsed who are used to referring to file shares by UNC paths of the form \\server\share\folder.
Tightened check to avoid handling file://C:/some/path as a UNC path.
Git 2.25.2 (March 2020) adds tests for this use-case.
See commit bfe2bbb (13 Feb 2020) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit fc25a19, 17 Feb 2020)
t5580: test cloning without file://, test fetching via UNC paths
Signed-off-by: Johannes Schindelin
On Windows, it is quite common to work with network drives. The format of the paths to network drives (or "network shares", or UNC paths) is:
\\<server>\<share>\...
We already have a couple regression tests revolving around those types of paths, but we missed cloning and fetching from UNC paths without leading file:// (and with backslashes instead of forward slashes). This lil' patch closes that gap.
It gets a bit silly to add the commands to the name of the test script, so let's just rename it while we're testing more UNC stuff.
