Re: Git project and GSoC 2026
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Jan 30, 2026, 09:32 UTC
- Message-ID
- <CAOLa=ZTK-PdJAYfDVPW3qLN+nBCe71Q=E8xohJzbFK=EH8sNkA@mail.gmail.com>
- In-Reply-To
- <CAP8UFD29LtG2dRRB4f6mZAHNGqDmDxUV4ULYw3w3OYg15ZBBYg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 12 quoted lines
> Hi, > > On Wed, Jan 28, 2026 at 9:28 PM Kaartic Sivaraam > <kaartic.sivaraam@gmail.com> wrote: > >> Just a gentle nudge for the project ideas. The deadline to apply for GSoC is Feb 3 18:00 UTC. We need the ideas page ready a couple of days before it at least. > > Thanks for the nudge! > >> Feel free to chime in to suggest ideas that would be achievable by someone new-ish to the community. If you're doubtful whether an idea would be relevant for GSoC, feel free to share the same and we can discuss it. > > Here are ideas I came up with:
Thanks Chris for leading this effort!
Show 31 quoted lines
> > 1) Continue the current work on removing global variables. > > 2) Finish, and then maybe improve, some work Eric Ju started a long > time ago on `git cat-file`. > > 3) Improve git-backfill, or maybe a different command, so it can > remove large local blobs when they are available on a promisor remote > (for clients who want to get back disk space). > > 4) Implement some kind of fetch order when more than 1 promisor remote > is configured (this order could be passed from servers to clients > through the promisor-remote protocol to make sure the fetches happen > in the optimal order). > > 5) Make the promisor-remote protocol useful when the server wants to > advertise "better-connected" remotes (not just remotes the server > uses) as Junio suggested some time ago (see > Documentation/gitprotocol-v2.adoc). > > 6) Improve `git repo info` so it can show more information than now. > > 7) Improve `git repo structure` so it can show more stats than now. > > 8) Improve fast-export/fast-import and maybe git-repo-filter regarding > commit and/or tag signatures. This might conflict with GitLab people > (including me) possibly working on that soon though. > > I would be willing to mentor any of them, but I don't have much > knowledge on `git repo`, so I think it makes more sense for me to > avoid 6) and 7).
I'd be willing to mentor any of the projects listed. I have a little context in all of these, but that's a good reason to understand more :)
Maybe we can also decide how many projects we are willing to mentor this year?
Karthik