The GVFS protocol does not support submodules, so disable the
status.submoduleSummary config setting. A user had this enabled
in their global config, but that caused "git status" to be much
slower. When enabled, this runs two "git submodule" subprocesses,
which are very slow.

I investigated disabling these subprocesses in Git when the repo
has no submodules, but it needs to run the processes to check for
untracked submodules. Thus, there is no efficient way to detect
that submodules exist or not in advance.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

…opy loop

The `ProductUpgrader` makes a backup of the `C:\Program Files\GVFS` folder before running the install, as a mechanism for backing out a failed upgrade. However, it copies that data into `C:\Program Files\GVFS\ProgramData\GVFS.Upgrade\Tools`, which can create a copy loop! This affected an actual user.

I'm not sure why this affects that one user but not another. In addition to adding more defensive programming (adding the target of the copy to the list of exclusions), I also added some extra tracing so we can see how these strings differ on this machine.

The GVFS protocol does not support submodules, so disable the
status.submoduleSummary config setting. A user had this enabled
in their global config, but that caused "git status" to be much
slower. When enabled, this runs two "git submodule" subprocesses,
which are very slow.

I investigated disabling these subprocesses in Git when the repo
has no submodules, but it needs to run the processes to check for
untracked submodules. Thus, there is no efficient way to detect
that submodules exist or not in advance.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

We have a short list of Git commands that are known to be safe to run in parallel because they do not update the index. This list did not include `git pack-objects`. This is blocking some legitimate use of the tool.

See microsoft/git#278

…when possible

Our release build is failing because we cannot download nuget due to TLS
1.2 changes. But we already require nuget.exe in an earlier step of the
build.

Require nuget.exe to be on the PATH, and update Readme.me accordingly.

It appears that during our build, we send some DLLs for signing, but the
versions we send have already been copied to other projects. Thus, we
ship versions of those DLLs that are unsigned.

Add extra versions of the DLLs that are currently being signed, except
include them in the GVFS.Windows project that is likely where they are
being copied as part of the build.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

…r signing

It appears that during our build, we send some DLLs for signing, but the
versions we send have already been copied to other projects. Thus, we
ship versions of those DLLs that are unsigned.

Add extra versions of the DLLs that are currently being signed, except
include them in the GVFS.Windows project that is likely where they are
being copied as part of the build.

Convert an inadvertent use of StringComparer.OrdinalIgnoreCase
to the relevant OS-specific PathComparer helper.

Convert an inadvertent use of `StringComparer.OrdinalIgnoreCase` to the relevant OS-specific `PathComparer` helper.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

See microsoft/git#283

…s/M174