VFS for Git support

[shiftkey]

Preview builds are available from Microsoft here: https://github.com/Microsoft/git/releases

There's MinGit-esque releases in there, which we could slipstream in here for experimental support.

I haven't thought much about the work to enable this in Desktop Electron, but some notes from @sanoursa:

• As long as you shell out to git.exe when interacting with a GVFS repo, you can expect that it’ll “just work” - with the exception of a few blocked commands like gc, fsck, repack, and for the time being, submodule

This all seems fine, we're not using those commands yet.

• GVFS introduces a new type of lock to ensure that GVFS’s background operations don’t collide with the user’s git commands. This GVFS lock is brokered by our new pre-command and post-command hooks that wrap every git command and ask GVFS if the git command can have the lock. Some git commands are whitelisted because we know they won’t interfere.

This seems fine too.

• Related to that, if you’re calling “git status” in the background, please pass in --no-lock-index. In addition to avoid the index lock, we also use that flag to skip grabbing the GVFS lock

This is something we'll need to do conditionally for Windows.

• The layout of a “gvfs clone” looks like the following:
  • <clone root>
    • .gvfs <-- this is where we store our GVFS metadata and logs
    • src <-- this is the actual git repo root
      • .git
      • <working directory>

This structure I think is the biggest change to how we manage things. Will likely have to think about how to manage this in the app.

[shiftkey]

cc @ethomson

[shana]

Related to that, if you’re calling “git status” in the background, please pass in --no-lock-index. In addition to avoid the index lock, we also use that flag to skip grabbing the GVFS lock

What are the implications of this flag?

[shana]

• The layout of a “gvfs clone” looks like the following:
  • <clone root>
    • .gvfs <-- this is where we store our GVFS metadata and logs
    • src <-- this is the actual git repo root
      • .git
      • <working directory>

This feels like a very arbitrary layout. Why not just add a .gvfs folder next to .git? Do we know why they're harcoding it this way?

Is there a good place to poke them about this? Their release repo doesn't have issues enabled :P

[ethomson]

It's not at all arbitrary. The source directory (the git working directory) is the one that's virtualized. The .gvfs folder needs to be on a proper filesystem - it can't be on the virtual filesystem, because it contains the data on how to find the virtual filesystem.

[shana]

@ethomson Ah, I see, that makes sense. That means that technically the working dir can be called anything and be virtualized anywhere, right?

[ethomson]

Yes, I think so, but don't quote me on that. I think that the src is just convention.

[shiftkey]

Bumping this to indicate the rename of the project to VFS for Git.

I had a look at the latest releases but they publish an installer - given this Git package is supposed to portable I wonder if I can even support VFS for Git in it's current form, or if they have plans for a Portable-esque package.

@ethomson who can I bug about this?

[rickhopkins]

If you could just alias the repo locally that would work... so instead of every gvfs repo being called src in the desktop client, just allow for an alias. Sourcetree does this I believe. Seems like a much more simple solution.

[ethomson]

@sanoursa would be the person to talk to about distribution or if there could be a distribution for gvfs that is the moral equivalent of "min git" or "portable git".

Out of curiosity, do you need to bundle this or can you call the end-user's gvfs? Are you concerned that you want to pin and ship the version yourself to avoid needing to know what the end-user has installed?

[shiftkey]

Out of curiosity, do you need to bundle this or can you call the end-user's gvfs?

@ethomson i'm trying to wrap my head around how coupled GVFS is to Git itself - I see the releases ship a version of GVFS and Git together, so does that mean other Git for Windows installations are unable to use GVFS? That's how I read it at least.

Are you concerned that you want to pin and ship the version yourself to avoid needing to know what the end-user has installed?

Essentially. I'm planning to upgrade Desktop to 2.18 next week and start evaluating 2.19 when that drops. If our embedded Git needs specific patches to work with GVFS that can be included when building Git for Windows from source, maybe that's the solution here.

[shiftkey]

@rickhopkins

If you could just alias the repo locally that would work... so instead of every gvfs repo being called src in the desktop client, just allow for an alias.

We don't detect or support a GVFS-enabled repository in Desktop, so this is likely reverting to vanilla Git behaviour, and I'd love to figure out how to properly manage GVFS-enabled repositories in the app. This discussion is for the tooling side that Desktop needs, as a pre-requisite.

[rickhopkins]

@shiftkey I'm not sure anything needs to change under the covers. Doesn't the desktop client just use whatever git version is installed on the machine? The git version that microsoft provides is supposedly a drop in replacement for git. The issue is that it sort of makes your repo have an additional level. So if your repo before we something like

• MyRepo/
  ---- .git/
  ---- .gitignore
  ---- file_1.txt
  ---- file_2.txt

After converting it to gvfs it would look like

• MyRepo/
  ---- .gvfs/
  ---- src/
  -------- .git/
  -------- .gitattributes
  -------- .gitignore
  -------- file_1.txt
  -------- file_2.txt

When you add the local repo to the desktop client you have to point it to the src folder. This makes it look in github desktop like every repo you have is called "src". If you could simply add a name or an alias field to the screen where you are adding the local repo, it would solve the issue for me. I could point to the "src" folder but call it something like "MyRepo" in the desktop client. Sourcetree allows for this functionality. Doesn't seem like it would require functionality change other than adding a field to the add local repo form.

[shiftkey]

@rickhopkins

Doesn't the desktop client just use whatever git version is installed on the machine?

No, we use this package (which supports Windows/macOS/Linux/ARM64) so the user doesn't need to have Git already installed.