Skip to content
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

Unable to extract a pack entry from irs-manual-demo.git #1621

Open
gl-yziquel opened this issue Oct 11, 2024 · 1 comment
Open

Unable to extract a pack entry from irs-manual-demo.git #1621

gl-yziquel opened this issue Oct 11, 2024 · 1 comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed help wanted Extra attention is needed

Comments

@gl-yziquel
Copy link

Current behavior 😯

Hi.

I tried to perform gix clone https://github.com/Unstructured-IO/irs-manual-demo.git

gix version: v0.37.0-503-g37c1e4c91 (i.e. latest HEAD).

I get:

Error: A pack entry could not be extracted

Caused by:
    The object a34aa97bb731bf5ca3a5831d8cef177235ed2265 could not be decoded or wasn't found

Expected behavior 🤔

It should work.

Git behavior

git clone succeeds.

Steps to reproduce 🕹

To reproduce, build latest gix, clone the repo, and see it fail.

@Byron Byron added help wanted Extra attention is needed acknowledged an issue is accepted as shortcoming to be fixed labels Oct 11, 2024
@Byron
Copy link
Member

Byron commented Oct 11, 2024

Thanks a lot for reporting! This is another incantation of this issue.

In short, the problem is that gitoxide can currently only handle delta-packs with ref-deltas pointing to objects already present in the object database. This is the case for typical efficient packs, but not every server side generates these, and apparently it's also possible to sneak these into GitHub which apparently doesn't recompress them completely.

This isn't easily fixable, as it requires an entirely different implementation of the resolver which right now is lightning fast, but only because it assumes efficient packs. The word efficient here means that it's always better to refer to a base object by its high-byte encoded offset into the same pack instead of by a fixed 20 byte SHA1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants