Git FileSystem

[danielang]

Hi @xoofx, do you already have any plans for the Git FileSystem? I am currently working on a project which require this capability. We already using ZIO and the project will benefit from this feature.

Perhapse we can collaborate to improve ZIO with a Git FileSystem.

Thank you for your awesome library!

[xoofx]

do you already have any plans for the Git FileSystem?

Myself no, but a PR is welcome or a separate project with its own NuGet if you want to keep a control on it. 😉

If you want to make a PR, this should be a separate project/NuGet as we should not introduce a dependency to LibGit2Sharp or similar to the core library.

[danielang]

Hi @xoofx, I've created a fork of ZIO and have just experimented a bit how to get files (their content) and directories from a specific commit.

I've already created a .NET Standard 2.0 DLL Project (Zio.GitFileSystem). Is this name okay? This DLL uses Libgit2Sharp (which needs .NET Standard 2.0) and of cause ZIO as reference 🙂

The GitFileSystem should be read-only in the first implementation like the ReadOnlyFileSystem. For each commit/branch you want to browse the developer has to create a new instance of GitFileSystem. Or should it be possible to switch the commit/branch by an extra method?

My first thought was that the GitFileSystem provides six constructors:

1. GitFileSystem(UPath repositoryPath, Commit commit)
2. GitFileSystem(UPath repositoryPath, Branch branch)
3. GitFileSystem(UPath repositoryPath, string committishOrBranchSpec)
4. GitFileSystem(Repository repository, Commit commit)
5. GitFileSystem(Repository repository, Branch branch)
6. GitFileSystem(Repository repository, string committishOrBranchSpec)

What do you think?

[xoofx]

I've already created a .NET Standard 2.0 DLL Project (Zio.GitFileSystem). Is this name okay?

Yes

Or should it be possible to switch the commit/branch by an extra method?

Hm, I think that an explicit model is better (so create a GitFileSystem per commit/branch) and that the current commit/branch is immutable in a GitFileSystem.

That's a start, we can reconsider this later based on usages.

What do you think?

Yep, that's a good start 👍

[danielang]

Okay 🙂 I'll report back.

[danielang]

Hi 🙂 I've implemented a first version of the GitFileSystem in a feature branch "feature/gitvfs" in my fork.

Can you please take a look if this implementation is going in the right direction.

Everything should work except from the "Metadata API" what should these methods return?

• The commit timestamp
• The timestamp when this file was commited

What do you think?

The "Watch API" is currently disabled. But a if the GitFileSystem was initialized with a branch files could changing. I must look for a hook to get notified by Libgit2Sharp when a new commit was added to the branch.

For testing I've already created a project. But I've never done such tests 😓 Could you help me with this?

[xoofx]

I checked the code, wondering why do you need to use a constructor that takes a IFileSystem and a subpath instead of initializing directly with a Repository object?

Using for example var ioPath = fileSystem.ConvertPathToInternal(SubPath); is not really solid, as you can have a MemoryFileSystem that would not have any counterpart on the disk.

On the other hand, is there a way in LibGit2Sharp to plug its backend to our own IFileSystem? (Afair, you can do this with the native libgit2 library, but not sure they have exposed this to the .NET version). That way, we could have a Repository that could work with a MemoryFileSystem which could be pretty useful.

[LimpingNinja]

@danielang Were you planning on creating a pull request for your gfs?

[danielang]

Hey @LimpingNinja Please check https://github.com/danielang/zio/tree/feature/gitvfs for the current state. It works fine for me. If @xoofx or you want I can make a PR.