Design new CLI usage

[sanoursa]

The options suggested so far for the CLI executable usage are:

• git vfs <verb>
• vfsgit <verb>
• vgit <verb>

I currently lean towards vfsgit as the entry point, because it more closely mirrors the name "VFS for Git".

We need to go through each of our verbs and ensure this design choice makes sense, but I don't see any obvious issues at the moment.

[sanoursa]

As stated earlier, I think vfsgit[.exe] is the best CLI name out of the options we've considered. For reference and review, here are all the verbs we support (just replacing gvfs with vfsgit)

• vfsgit clone <Repo URL> [<Clone Root Path>] [--local-cache-path <Local Cache Path>] [--cache-server-url <Name>|<URL>] [-b|--branch <Branch>] [--no-prefetch] [--no-mount] [--single-branch] [--internal_use_only_service_name <Service Name>]

  • Notes: I think we should deprecate/remove the final two params.
  • I don't think we have any actual uses or users for --single-branch, and it has no real benefit anyway.
  • The --internal_use_only_service_name param is used by functional tests only, and we should consider passing that in via an environment variable instead to clean up the CLI. Same goes for all verbs (for brevity I'm omitting it on all other verbs, but it is implied everywhere)

• vfsgit mount [<Repo Root Path>] [-v|--verbosity Verbose|Informational|Warning|Error] [-k|--keywords Any|Network]

  • Notes: I don't know if we have any remaining uses for the --verbosity and --keywords flags, consider removing.

• vfsgit cache-server has various forms:

  • vfsgit cache-server [<Repo Root Path>] [--get]
  • vfsgit cache-server [<Repo Root Path>] --set <Name>|<URL>
  • vfsgit cache-server [<Repo Root Path>] --list

• vfsgit dehydrate [<Repo Root Path>] [--no-status] [--confirm]

  • Notes: Remove "experimental" disclaimer?

• vfsgit diagnose [<Repo Root Path>]

• vfsgit log [<Repo Root Path>] [--type clone|dehydrate|mount|prefetch|repair|service]

  • Notes: The type flag was added more for our own convenience than any customer usage. Consider dropping it.

• vfsgit prefetch has various forms:

  • vfsgit prefetch [<Repo Root Path>] -c|--commits [--verbose]
  • vfsgit prefetch [<Repo Root Path>] [--files <semicolon-delimited list of file paths, prefix * wildcards allowed>] [--folders <semicolon-delimited list of folder paths, no wildcards>][--folders-list <path of file containing newline-delimited paths of folders, no wildcards>] [--hydrate] [--verbose]
  • Notes: do we still need the --verbose flag?

• vfsgit repair [<Repo Root Path>] [--confirm]

  • Notes: Remove "experimental" disclaimer?

• vfsgit service has various forms:

  • vfsgit service --list-mounted
  • vfsgit service --unmount-all
  • vfsgit service --mount-all
  • Notes: This verb name is very Windows specific (it assumes knowledge of our GVFS.Service Windows Service). Now that we're cross-platform, consider renaming this verb to something more generic.

• vfsgit status [<Repo Root Path>]

• vfsgit unmount [<Repo Root Path>] [--skip-wait-for-lock]

• vfsgit upgrade is still in progress

I think all of these uses map over to the new name fairly well, and we should use the opportunity to clean up where appropriate and won't break existing customers.

[alameenshah]

Should we add vfsgit config too...

[Nirmal4G]

I currently lean towards vfsgit as the entry point, because it more closely mirrors the name VFS for Git.

I currently lean towards git vfs as the entry point, because it more closely mirrors the git lfs command.

I go with the Git VFS for product name too, since Git LFS is a thing!

Then again, it's too late now! You guys already started naming VFS for Git everywhere!!

[Nirmal4G]

OK, I didn't see the whole vendor agnostic. Sorry about that!

But still you can go with Git VFS for git specific implementation and separate the generic file system driver to say, "Windows Projected File System (PFS) Driver" or "Windows Virtual File System (VFS) Driver"

And have a common cli that controls the VFS Driver and the integration to various 3rd party extensions (like OneDrive, Dropbox and now Git) to be called vfs.exe or pfs.exe!

[aaronfranke]

The difference between git lfs and git vfs is that when the latter is shortened to gvfs it becomes the same as the name of another product. Which is why we can't expect to use the same formula as LFS.

Also, Microsoft has a big problem with naming things already, let's try not to make it worse. We are talking about command-line interfaces here, right? Or is this the common language infrastructure?

[Nirmal4G]

Then don't name it as GVFS, name it as Git VFS and tell people to not to shorten it. Both names are different!

Also, I never seen Git LFS shortened to GLFS in the wild. Have you?