refs other than heads(branches),tags,hashes

[andreineculau]

Nice initiative 👏 I had a look at your source code and just wanted to confirm and highlight that your "ref" seems to only handle refs/heads/*, refs/tags/* and hashes. Except there can be other refs. git notes command and https://github.com/google/git-appraise store content under refs/notes, etc.

[billziss-gh]

HUBFS currently handles:

• Branches (refs/heads) and will also list them when you do ls or dir.
• Tags (refs/tags) which are not listed when you do ls or dir, but can be opened (i.e. you can cd into them and access files in them).
• Commit hashes are also supported. For example, if you want to access files under the commit COMMIT you can use the path / OWNER / REPO / COMMIT / PATH / TO / FILE.

It may be worthwhile to add support for additional refs. Please keep in mind that currently the primary use case scenario for HUBFS is to allow easy browsing and building of projects without cloning. It is not intended as a replacement for the regular git workflow.

[andreineculau]

Please keep in mind that currently the primary use case scenario for HUBFS is to allow easy browsing

It is exactly this that makes hubfs for my projects/teams. We use other refs to push e.g. build artifacts like logs/etc . So having a filesystem that could simply show the contents instead of a complicated git flow would be magical (which can be hidden behind a script ofc but nothing as smooth as an ephemeral file system)

One doesn't need to look for edge cases - think pullrequest refs that already have merged your PR to the target branch. Easy to get access to instead of git/hub/gh/etc invocations.

[billziss-gh]

I discuss below problems and potential solutions:

• Currently HUBFS organizes its namespace in the pattern / owner / repo / ref / path and employs a ref "flattening" scheme. By ref flattening I mean that it merges ref's from refs/heads and refs/tags and also replaces any slashes (/) with spaces so that release/1.0 becomes release+1.0. (In the current release slashes (/) are replaced with spaces but this will be changed in the next release to avoid problems with spaces in paths.)

  The ref flattening allows HUBFS to quickly determine the "kind" of a path component. For example, in the path /winfsp/hubfs/master/README.md HUBFS can quickly determine that winfsp is the owner, hubfs is the repo, master is the ref and /README.md is the path to repository content.

  HUBFS could also support an alternative ref flattening scheme (perhaps when a command line option is supplied). Some example ref's in this proposed scheme follow:

  • branches: heads+master
  • tags: tags+v1.0
  • notes: notes+commits
  • PR's: remotes+origin+pull+3+head
  • etc.

  @andreineculau I do not know if this alternative scheme gets you what you need.

• Currently HUBFS can only support ref's that point to commit objects.

[billziss-gh]

HUBFS now has a -fullrefs option that can be used to make all refs available.

Related commits: 1c74be74ceff3eb60c5e5a7de9bab5405a071b53, 599c0a4646e143d8b9585d46ee51c8d93a039aef