Why is VSTS private agent trying to GIT Checkout?

Question

I have a VSTS private agent attempting to run a standard "Get Sources" build step, executing against a GIT repository.

I have two issues:

1. Why is the agent trying to "checkout" the repository after pulling the files? As I understood, perhaps incorrectly, the "checkout" command is useful if I plan on tracking changes to the files. In this case, all I want to do is deploy them, so checkout seems unnecessary. I don't see any configuration options for the "Get Sources" build step to change this behavior. It seems like a simple "Git Pull" should be sufficient to grab the latest changes.

2. Checkout seems to complete, but the agent is reporting a failure with no reason given and the step bombs out. I have no idea why. Are there any other logs I can look for?

Here are the relevant snipped log entries:

2018-04-17T22:40:56.3673827Z ##[section]Starting: Get Sources
2018-04-17T22:40:56.6017206Z Syncing repository: MyRepositoryName (TfsGit)
2018-04-17T22:40:56.6345172Z Prepending Path environment variable with directory containing 'git.exe'.
2018-04-17T22:40:56.6731072Z ##[command]git version
2018-04-17T22:40:57.6691314Z git version 2.14.3.windows.1
2018-04-17T22:40:57.7442618Z ##[command]git config --get remote.origin.url
2018-04-17T22:40:58.0387545Z ##[command]git config gc.auto 0
2018-04-17T22:40:58.2060676Z ##[command]git config --get-all http.https://accountname.visualstudio.com/TeamName/_git/MyRepositoryName.extraheader
2018-04-17T22:40:58.3387349Z ##[command]git config --get-all http.proxy
2018-04-17T22:40:58.5041394Z ##[command]git -c http.extraheader="AUTHORIZATION: bearer ********" fetch --tags --prune --progress --no-recurse-submodules origin
2018-04-17T22:41:01.0697064Z ##[command]git checkout --progress --force aa3e90152725f1f2489f9d657e02d29336a33ca6
2018-04-17T22:41:05.7394799Z Checking out files:   0% (85/285855)   
2018-04-17T22:41:06.7309776Z Checking out files:   0% (162/285855)   
...
2018-04-18T00:09:28.7067967Z Checking out files: 100% (285855/285855), done.
2018-04-18T00:09:34.7445251Z Note: checking out 'aa3e90152725f1f2489f9d657e02d29336a33ca6'.
2018-04-18T00:09:34.7445879Z 
2018-04-18T00:09:34.7446180Z You are in 'detached HEAD' state. You can look around, make experimental
2018-04-18T00:09:34.7446601Z changes and commit them, and you can discard any commits you make in this
2018-04-18T00:09:34.7448203Z state without impacting any branches by performing another checkout.
2018-04-18T00:09:34.7448381Z 
2018-04-18T00:09:34.7448593Z If you want to create a new branch to retain commits you create, you may
2018-04-18T00:09:34.7448803Z do so (now or later) by using -b with the checkout command again. Example:
2018-04-18T00:09:34.7448980Z 
2018-04-18T00:09:34.7449144Z   git checkout -b <new-branch-name>
2018-04-18T00:09:34.7449467Z 
2018-04-18T00:09:34.7449669Z HEAD is now at aa3e90152... Deleted .vs
2018-04-18T00:09:35.7714386Z ##[error]Git checkout failed with exit code: 1
2018-04-18T00:09:35.7961679Z ##[section]Finishing: Get Sources

Answer 1

The checkout is necessary to populate the working tree, in order for the task defined in VSTS to operate on the files checked out.

It does checkout here a commit, not a branch, meaning it results in a detached HEAD, not meant to track any new commits.

I don't know of more detailed logs.
Maybe the last "Deleted .vs" encounters some error during that last step (like a process preventing the deletion by keeping an handle).
Generally, I try to connect to the build agent server, and reproduce the git command to see what happens.

---

The OP reports in the comments:

I found a "path too long" error waaaay up in the checkout process.

In that case, if you can, configure the job to be checked out in a drive letter defined with subst (see option 2).

Of check if you can do a partial (sparse) checkout, avoiding the part of the Git repo with that long path.