in GVFS/GVFS.Hooks/Program.cs [292:364]
private static bool ShouldLock(string[] args)
{
string gitCommand = GetGitCommand(args);
switch (gitCommand)
{
// Keep these alphabetically sorted
case "blame":
case "branch":
case "cat-file":
case "check-attr":
case "check-ignore":
case "check-mailmap":
case "commit-graph":
case "config":
case "credential":
case "diff":
case "diff-files":
case "diff-index":
case "diff-tree":
case "difftool":
case "fetch":
case "for-each-ref":
case "help":
case "hash-object":
case "index-pack":
case "log":
case "ls-files":
case "ls-tree":
case "merge-base":
case "multi-pack-index":
case "name-rev":
case "pack-objects":
case "push":
case "remote":
case "rev-list":
case "rev-parse":
case "show":
case "show-ref":
case "symbolic-ref":
case "tag":
case "unpack-objects":
case "update-ref":
case "version":
case "web--browse":
return false;
/*
* There are several git commands that are "unsupported" in virtualized (VFS4G)
* enlistments that are blocked by git. Usually, these are blocked before they acquire
* a GVFSLock, but the submodule command is different, and is blocked after acquiring the
* GVFS lock. This can cause issues if another action is attempting to create placeholders.
* As we know the submodule command is a no-op, allow it to proceed without acquiring the
* GVFSLock. I have filed issue #1164 to track having git block all unsupported commands
* before calling the pre-command hook.
*/
case "submodule":
return false;
}
if (gitCommand == "reset" && args.Contains("--soft"))
{
return false;
}
if (!KnownGitCommands.Contains(gitCommand) &&
IsAlias(gitCommand))
{
return false;
}
return true;
}