-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nozlib #115
Merged
Merged
Nozlib #115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
08d27a9
to
1c60e7e
Compare
For now only in the metadata (the _oasis and opam files)
This has moved to Git.Inflate.
The goal is that all Git objects expose a Object.S signature and maybe a functor to create an Object.IO (parametrized by digest and/or inflate algorithms).
Seems that in some cases the side-band messages do not work as expected... need to investigate.
This means that these values actually are not present in the pack file.
Shallow values are now properly translated to PIC values and the deltas are not skipped anymore. The new delta objects points to the shallow PICs. It's possible that two delta points to two different shallow PICs with the same hash, that's annoying but should not be a bug as shallow PICs are not serialized in the pack file anyway (so no risk of duplciation).
…ones Also advertize that our client supports thin-pack and ofs-delta
Fix mirage#114 I think we do not send enough of them.
…fe to run Sys commands
This is not supported by GitHub (as it does not advertise "allow-reachable-sha1-in-want") so use a commit corresponding to the tag 1.6.0 instead. Fetch a hash corresponding to a tag instead
So the server sent us a pack file way too big.
Add more tests and fix the existing ones.
Now the client computes the "slice" of commits between the ones he knows about and the ones the server knows about. This should optimize for most of the cases. There is still a non-optimal case: when both the client and the server have updated the same reference. In that case, we perform very badly. A possible fix would be to send all the commits again in that case, but that's not very elegant...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
That's the first step to make it more Xen/JS friendly. The second one is to abstract the SHA1 implementation. Patches landing soon.