Comments (4)
You know how great it is to have you here thanks to the gloomy language in the keybase chatroom, so this message is just for the world to see :).
That said, let's get to it!
Remote capabilities would be our highest priority, being able to fetch changes from a peer
in our case and the peer responding with the changeset.
I believe this is feature complete and you can fetch everything that 'git' can fetch.
The Ref DB would be our next highest priority.
It's not implemented except for verifying ref names, but getting what you need there will be quite straight forward and a good exercise to get started with the code base. Of course I am happy to assist there, having implemented it once myself.
Followed by local capabilities, we're happy to use libgit2 here during a transitionary period.
This is generally how I thought it could be done as well, use libgit2 for everything while you can't use gitoxide for it, and choke it out in order of pain.
As I mentioned above, the fetch exchange
would be top of our list. Maybe you could flesh out what's complete here, what's missing, and where
we could start looking in the code-base to understand this better.
To elaborate on our needs in this area, we need to implement our own transport
layer, so we'd be interested in what the gitoxide API looks like here.
Let's setup a zoom call for 90 minutes to 2h and I will guide you through everything you want to know. This is most certainly more productive when done interactively.
We will have a lot of refs, which we constantly read and update. Eventually, we will want a
"real" database, but if we keep using libgit2, we would have to teach it to use a custom backend. As
a middleground, if gitoxide supports "packed refs" (that's a single file containing all the refs),
this would already be an improvement (that's assuming libgit2 loads the refs lazily).
Since you are the first implementing ref reading and writing, you would be able to define how it should be. I am sure we find something that's both simple while supporting what you need. My suggestion is to keep it 'dumb' for now and wait until the API settles and packed-refs get too slow. Then a trait might do the trick. My first thoughts on this, I am happy to discuss this with you in our session.
For reference handling, we need to be able to read references, perform commits, and compute merge
basing. This functionality is necessary for our handling of documents on the network.
This would probably be happening in in git-repository
, and once git-ref
is implemented you should be ready to traverse the commit graph and generally do more useful things.
The V2 implementation
I am probably failing to understand what exactly you are talking about but can tell you that much: The git-protocol
crate contains everything you are looking for, and I believe the client has all control it could ever want as the 'base' implementation truly only takes care of doing the necessary communication while the content is controlled by the implementor of a trait.
As pack-send
is not implemented, there is no server side to this in gitoxide
yet and you could be the ones to define how this looks like, giving you all the control you need beyond of what's needed for a standard git client.
We're excited about the prospect of using gitoxide and being able to contribute to it, however,
we've only got so much person-power at the moment. So this is a good first step in figuring out how
much work is involved. After that, we can work out how much time we delegate to helping out on the
project.
Yes, let's make sure your work is surgical and efficient - best to talk in person and I will reach out to you in keybase to set something up.
It's going to be great 👍 !
from gitoxide.
I think git-config was accidentally skipped. Even though the read and write API is sketched out, the parser is missing. #31 is tracking the issue.
from gitoxide.
I'm also working on the parser right now, as we speak. I'll see what type of progress I can get done over the weekend - dangerous
(the parser lib we're wanting to use) seems pretty straightforward, I'm just reading through the git config spec from Git's C source code to make sure I get 100% coverage.
I'll make sure I write tests for that config parser as well
from gitoxide.
That's so great to hear, thank you! If there is anything stopping you, please don't hesitate to reach out in our realtime channel for quick support.
from gitoxide.
Related Issues (20)
- Checkout fails when Windows symlinks have strangely named targets HOT 2
- PermissionDenied checking Windows symlink target is misinterpreted as collision HOT 3
- Test suite does not assert directory symlink creation HOT 2
- `gix_mailmap::Snapshot` does not implement `Debug` or `Eq` HOT 4
- gix cannot clone a repo with a branch called HEAD HOT 2
- ssh clone does not correctly detect the location of ssh.exe HOT 12
- parsing failure of invalid author/committer line - missing space before email HOT 3
- gix-diff make_diff_repo test fixture archive is always regenerated HOT 2
- many_different_states fails on Windows with GIX_TEST_IGNORE_ARCHIVES=1 HOT 3
- 9 tests rely on commands like `ln -s` making copies instead of symlinks on Windows HOT 4
- gix-config set configuration values HOT 1
- OSS-Fuzz issue 70323 HOT 1
- Something went wrong... & Merge conflict after working on another device HOT 1
- `gix clean -xde` deletes whole repo if `.gitignore` lists `*` or `/` HOT 6
- The kstring integration in gix-attributes is unsound HOT 5
- Fallback to git commands? HOT 3
- `gix clean` with `-r` or `-xd` deletes the repo's own nested worktrees HOT 5
- audit uses of `as_ref()` and remove those that are ambiguous HOT 6
- gitoxide fails to compile with bstr 1.9.2 HOT 1
- `gix clean -xde` deletes the repo's own hidden nested worktrees, but they are not really hidden HOT 5
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.