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
SoC-2026-Ideas.md
Outdated
| * Lucas Seiki Oshiro < lucasseikioshiro@gmail.com > | ||
| * Chandra Pratap < chandrapratap3519@gmail.com > | ||
|
|
||
| ### Improve signature handling in fast-export/fast-import and git-filter-repo |
SoC-2026-Ideas.md
Outdated
| 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.
SoC-2026-Ideas.md
Outdated
| 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.
SoC-2026-Ideas.md
Outdated
| 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.
There was a problem hiding this comment.
Removed the client side overrides part. Is that sufficient or should the idea be removed?
There was a problem hiding this comment.
I think that's sufficient. Thanks.
We could also say that this area of the code is being worked on these days, so coordination with others' work will likely be required or something like 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.
There was a problem hiding this comment.
Just saying "it would be useful in some cases" instead of "it would be more useful" is enough here I think.
| - 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.
There was a problem hiding this comment.
Do we need to remove the idea then?
There was a problem hiding this comment.
No like for the other idea about promisor remotes, we could just say that it might require coordination with others working in that area.
@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. |
|
I've changed the ideas page based on your suggestion. Kindly check and let me know if any other ideas in which you've commented needs to be removed. |
|
@sivaraam thanks! I will merge this and make a few changes on top. |
|
I have made a few additional changes in c4e2a16. |
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/