Closed andreineculau closed 2 years ago
HUBFS currently handles:
refs/heads
) and will also list them when you do ls
or dir
.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
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.
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.
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:
heads+master
tags+v1.0
notes+commits
remotes+origin+pull+3+head
@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.
HUBFS now has a -fullrefs
option that can be used to make all refs available.
Related commits: 1c74be74ceff3eb60c5e5a7de9bab5405a071b53, 599c0a4646e143d8b9585d46ee51c8d93a039aef
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 underrefs/notes
, etc.