Comments (20)
Thanks for letting me know! The current stance of gitoxide is to not implement the 'dumb' protocol on the client side. This is due to it being seemingly underspecified.
From what's stated here I gather that you are interested in the server side. There I also don't know how it would work at all to generate these caches and what the problems are specifically that you are running into.
I think further comments here could try to fill in the gaps to understand the requirements and allow an implementation to happen.
Thank you.
from gitoxide.
Nah, we only need it on the "client" (the ability to clone).
Take a look at https://github.com/ganarchy/GAnarchy
On the "server", or more specifically on the git host, plain git
works fine - git
is good enough at generating static pages when pushing over SSH, so there's no point trying to replace it there.
from gitoxide.
I took a cursory look at GAnarchy but it didn't jump at me how gitoxide could help there.
Since the latter isn't able yet to do an entire clone itself and lots of features are missing, I recommend checking back when there is more of the feature set that I think you would need.
In the meantime, I am closing this issue as it lacks the detail necessary to aid any implementation.
from gitoxide.
These would be replaced with a Gitoxide-based equivalent: https://github.com/ganarchy/GAnarchy/blob/ganarchy/ganarchy/git.py
Many of the repos here do not support the v1/v2 protocol: https://github.com/ganarchy/ganarchy.github.io/blob/master/index.toml
from gitoxide.
The "dumb" protocol is simply ".git
dir over HTTP"
Since HTTP doesn't provide an index, git has to provide that index, but otherwise you just have a .git
like you would on a filesystem. This comes with all the stuff a normal .git
comes with including packfiles and the like.
We'd like to ask for this again, as our plan is to have self-embedding git repos for our HTTP-based projects, and it'd be nice if gitoxide could handle them so we don't need to require system-wide git.
from gitoxide.
Welcome back!
I took a cursory look at git.py
and thought that a lot of that should be doable in gitoxide
already. When it comes to maintaining an index to support the 'dumb' protocol, I would think that something like this exists or can be written by the ganarchy
project as a git hook maybe.
By the end of this year gitoxide
will be production ready for cloning/fetching repositories and checking out a worktree correctly and completely, if that helps.
from gitoxide.
Can gitoxide fetch all of the repos listed here? https://ganarchy.autistic.space/index.toml
This is the main blocker for us being able to use gitoxide.
(Also, that new git.py
(it is updated from when it was originally linked) was written specifically to parallelize a large amount of git fetch
. And it does an amazing job at that.)
from gitoxide.
Here is a listing of the supported transport protocols - dump http is not among them so I presume gitoxide
cannot fetch these repos. It looks like git2
also doesn't support this protocol, so the chances of ever supporting it on the client side in gitoxide
aren't high unless the implementation is contributed.
GitHub doesn't support line-links in markdowns unfortunately, so here is what the link above should have displayed.
from gitoxide.
how hard would it be to use the on-disk format code ("the on-disk format must remain compatible, and we will never contend with it.") in the HTTP transport?
(it'd be nice to reuse it so it can be kept in sync... vs maintaining a separate copy)
from gitoxide.
how hard would it be to use the on-disk format code ("the on-disk format must remain compatible, and we will never contend with it.") in the HTTP transport?
I don't know how these two related and would assume one is entirely independent of another. So one would probably have to find out.
from gitoxide.
the static pages protocol is just the on-disk format over HTTP. so they're very related.
decoupling them allows better transfer optimizations but then you kinda have to maintain the same thing twice.
from gitoxide.
Your work will be valuable as it will pave the way for eventually merging such capability back into mainline or be the basis for a backport. It's not on my agenda at all to add static http support, but I am happy to assist with questions should they arise on your own journey on getting it done.
from gitoxide.
hmm, thoughts on optimizing gitoxide for network-attached storage and the like? (gitoxide over google drive maybe?) such work would likely benefit attempts to add static pages protocol support (at least, using shared code).
basically, can you make the on-disk format driver backend-agnostic and optimized for latency?
from gitoxide.
hmm, thoughts on optimizing gitoxide for network-attached storage and the like?
No. But I think a first step would be to get anything to work in this regard.
from gitoxide.
actually hmm does gitoxide have support for VFS and local filesystem clone?
from gitoxide.
gitoxide
can perform a git-aware clone from a location specified by path. Since I don't know what VFS means exactly in this context, I'd say 'no' to this one.
from gitoxide.
hmm... does that mean this is unsupported?
-l, --local
When the repository to clone from is on a local machine, this flag
bypasses the normal "Git aware" transport mechanism and clones the
repository by making a copy of HEAD and everything under objects
and refs directories. The files under .git/objects/ directory are
hardlinked to save space when possible.
If the repository is specified as a local path (e.g.,
/path/to/repo), this is the default, and --local is essentially a
no-op. If the repository is specified as a URL, then this flag is
ignored (and we never use the local optimizations). Specifying
--no-local will override the default when /path/to/repo is given,
using the regular Git transport instead.
NOTE: this operation can race with concurrent modification to the
source repository, similar to running cp -r src dst while modifying
src.
from gitoxide.
That is unsupported indeed - gitoxide
currently uses 'git-aware' mechanisms only. Local clone optimizations can happen at some point though, it's just not a priority yet.
from gitoxide.
ahh. hmm...
"VFS" just means virtual filesystem. e.g. sshfs. however we now realize that wouldn't work for implementing this. we think we just have to do it properly... does gitoxide support http/2 (especially multiplexing)? that would help us a lot. where would a proper implementation of this go?
from gitoxide.
http is supported in a blocking fashion via curl
and the implementation of that is here: https://github.com/Byron/gitoxide/blob/9509ce4faeca8b4e1527bac625370403495bb03c/git-transport/src/client/blocking_io/http/mod.rs .
Since you are interested in static http support, I recommend adding support for it into the curl-based http implementation. I think right now it specifically checks for the 'smart' transport, and with the right test or two it should be possible to support the 'dumb' one as well without breakage.
from gitoxide.
Related Issues (20)
- OSS-Fuzz issue 64904 HOT 1
- update ring dependency HOT 4
- Inconsistency in gix clone with repo url with a dot. HOT 1
- oxidize `lilgit` HOT 1
- `gix-archive` - submodule support
- Updating packed-refs fails on Windows if `mmap`-ed (i.e. file size is over 32KiB) HOT 6
- OSS-Fuzz issue 65196 HOT 1
- Consider a `crates` folder HOT 1
- OSS-Fuzz issue 65229 HOT 1
- OSS-Fuzz issue 65231 HOT 1
- some dependencies are yanked HOT 1
- gitoxide requires miniz_oxide even when building with libz-ng HOT 3
- OSS-Fuzz issue 65351 HOT 1
- gix-index failing to build on NetBSD HOT 3
- Provide usage examples for the `Find` trait HOT 3
- Create a git wrapper that polyfill's unsupported behaviour HOT 1
- Rewrite tracker panics on BlobExecutable HOT 2
- OSS-Fuzz issue 65492 HOT 1
- make `ItemSliceSync` safe HOT 15
- OSS-Fuzz issue 65543 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitoxide.