SoC-2026: add more ideas based on Christian's suggestions #820
Conversation
sivaraam
force-pushed
the
gsoc-2026-more-ideas
branch
from
4ab0e9c to
4d6e764
Compare
| * Lucas Seiki Oshiro < lucasseikioshiro@gmail.com > | ||
| * Chandra Pratap < chandrapratap3519@gmail.com > | ||
|
|
||
| ### Improve signature handling in fast-export/fast-import and git-filter-repo |
| remotes. The order could be: | ||
| - Configured locally by the client | ||
| - Advertised by servers through the promisor-remote protocol | ||
| - Determined dynamically based on network conditions or other heuristics |
There was a problem hiding this comment.
I am not sure the order should depend on network conditions or other heuristics.
| This project aims to improve `git-backfill` (or create a new command) to allow | ||
| clients to remove large local blobs when they are available on a promisor remote. | ||
| This would help users who want to get back disk space while maintaining the ability | ||
| to re-fetch objects when needed. |
There was a problem hiding this comment.
A big challenge is that it's not yet clear what command this feature should belong to and its UI should look like.
I have suggested git backfill, but maybe git gc, git repack, git maintenance, or a new command are better. Finding the right place and the right UI for this command could be quite time consuming.
There was a problem hiding this comment.
Maybe we could say that the contributor will likely need to engage in a number of discussions and should be willing to work on prototypes and likely modify those prototypes often. Or something like that.
| The key challenge is designing a flexible system that allows servers to | ||
| communicate their preferred fetch order to clients (to ensure optimal | ||
| performance and cost management) while still allowing client-side overrides | ||
| when appropriate. |
There was a problem hiding this comment.
I think allowing client-side overrides of what the server advertises is a separate topic altogether.
One challenge is that I am working on other parts of the 'promisor-remote' capability already, so there could be conflicts with that.
|
|
||
| Currently, the promisor-remote protocol allows servers to advertise remotes | ||
| that the server itself uses as promisor remotes. However, as suggested by | ||
| Junio Hamano, it would be more useful if servers could advertise |
There was a problem hiding this comment.
I am not sure if it would be "more useful" I think it depends on the use case. But yeah it could certainly be useful in some cases.
| - Implementing server-side logic to determine and advertise appropriate remotes | ||
| - Implementing client-side handling of these advertisements | ||
| - Designing the protocol extension with backward compatibility in mind | ||
| - Testing with various network topologies |
There was a problem hiding this comment.
One challenge for this one too is that I am working on other parts of the 'promisor-remote' capability already, so there could be conflicts with that.
@sivaraam, thanks a lot. I have left a number of comments. Except for "Improve signature handling in fast-export/fast-import and git-filter-repo" I think we should indeed add those ideas but be clear about the challenges that contributors would likely face. |
2 participants
I've tried to include more project ideas based on @chriscool suggestions. Kindly review if the description appears fine or if does need more tweaking.
Ref: https://lore.kernel.org/git/CAP8UFD29LtG2dRRB4f6mZAHNGqDmDxUV4ULYw3w3OYg15ZBBYg@mail.gmail.com/