-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
Add object pool interface and refactor related code #36298
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
Conversation
|
You just don't know what you are doing. Such design is definitely wrong. You should never make an "Object" (which is also a horribly bad name) contain stateful fields. |
I adjusted the interface of |
|
Besides those problems, the more essential problem is: such design doesn't help the roadmap like #34651 What you does in this PR is just "rename NewBatch to NewObjectPool / NewBatchCheck to NewObjectInfoPool", there is no real improvement. You still have two "batch cat file" related structs and two processes. If your goal is something like #34651 , you need a design for it and really does the refactor, but not just moving and renaming code. |
Yes. This PR does not address #34651, and at the moment I don’t have a clear solution for that issue. The new interface introduced here allows us to use the interface |
|
If you don't have a clear solution for that issue, I don't see why&how you can "support three types of implementations going forward: the existing command-based implementation, a go-git–based implementation, and a remote command–based implementation". Just more rubbish. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I sent #36313 which will replace this one and the new interface will be suitable for git batch-command. This will be closed. |
Replace the
Batchinterface with the newObjectInfoPoolandObjectPoolinterfaces. This avoids exposing thewriterand limits access to a read-only interface for Git object content. In addition, this abstraction makes it possible to support alternative implementations, such as a go-git–basedObjectPoolor a remoteObjectPool, in the future.