|
| 1 | +--- |
| 2 | +layout: default |
| 3 | +title: SoC 2024 Ideas |
| 4 | +navbar: false |
| 5 | +--- |
| 6 | + |
| 7 | + |
| 8 | + |
| 9 | +This is the idea page for Summer of Code 2025 for Git. |
| 10 | + |
| 11 | +*Please completely read the [general application information](https://git.github.io/General-Application-Information) |
| 12 | +page before reading the idea list below.* |
| 13 | + |
| 14 | +## Summer of code main project ideas |
| 15 | + |
| 16 | +**Students**: Please consider these ideas as starting points for |
| 17 | +generating proposals. We are also more than happy to receive proposals |
| 18 | +for other ideas related to Git. Make sure you have read the "Note |
| 19 | +about refactoring projects versus projects that implement new |
| 20 | +features" in the [general application information](https://git.github.io/General-Application-Information) |
| 21 | +page though. |
| 22 | + |
| 23 | +### Note about limit of project selection |
| 24 | + |
| 25 | +Kindly note that considering the bandwidth of available mentors, the |
| 26 | +Git project would only mentor up to 2 contributors this year. |
| 27 | + |
| 28 | +This is not a hard and fast rule. It may change if more community members are |
| 29 | +willing to mentor in the coming days. For instance, this may happen when |
| 30 | +a new project is proposed and some community member volunteers to mentor |
| 31 | +the same. |
| 32 | + |
| 33 | + |
| 34 | +### Consolidate ref-related functionality into git-refs |
| 35 | + |
| 36 | +This project aims to streamline Git's reference management into the existing |
| 37 | +`git-refs` command by consolidating functionality currently spread |
| 38 | +across multiple commands. The new command will provide subcommands for listing, |
| 39 | +getting, checking existence, writing, and optimizing references, replacing the |
| 40 | +functionality currently handled by git-update-ref(1), git-for-each-ref(1), |
| 41 | +git-show-ref(1), and git-pack-refs(1). |
| 42 | + |
| 43 | +The consolidation work should ensure backward compatibility with existing |
| 44 | +commands. The work involves C programming in Git's codebase, creating |
| 45 | +comprehensive tests, and updating documentation. |
| 46 | + |
| 47 | +Required skills include C programming, familiarity with Git's codebase, and experience with command-line tool development. The project is expected to take 12 weeks, with existing commands being maintained for backward compatibility while development focuses on the new unified interface. |
| 48 | + |
| 49 | +Getting started: Build Git from source, study the existing ref-related commands, and submit a micro-patch to demonstrate familiarity with the codebase. |
| 50 | + |
| 51 | +_Expected Project Size_: 175 hours or 350 hours |
| 52 | + |
| 53 | +_Difficulty_: Medium |
| 54 | + |
| 55 | +_Languages_: C, shell(bash) |
| 56 | + |
| 57 | +_Possible mentors_: |
| 58 | + |
| 59 | +* Patrick Steinhardt < <[email protected]> > |
| 60 | +* Jialuo She < <[email protected]> > |
| 61 | + |
| 62 | + |
| 63 | +### Refactoring in order to reduce Git's global state |
| 64 | + |
| 65 | +This project focuses on modernizing Git's environment handling by refactoring |
| 66 | +the `environment.c` code to reduce global state. The goal is to move environment |
| 67 | +variables and configuration from global scope into more appropriate local |
| 68 | +contexts, primarily into the `struct repository` / `struct repository_settings` |
| 69 | +structure. This architectural improvement will make the codebase more |
| 70 | +maintainable and potentially enable better multi-repository handling in the |
| 71 | +future. The project involves careful refactoring of Git's core environment |
| 72 | +handling code, requiring strong C programming skills and attention to detail. |
| 73 | + |
| 74 | +The student will identify global variables that can be moved to local scope, |
| 75 | +implement the necessary structural changes, and ensure all affected code paths |
| 76 | +continue to work correctly. This includes updating tests, fixing any |
| 77 | +regressions, and documenting the architectural changes. |
| 78 | + |
| 79 | +_Expected Project Size_: 90 or 175 hours or 350 hours |
| 80 | + |
| 81 | +_Difficulty_: Medium |
| 82 | + |
| 83 | +_Languages_: C, shell(bash) |
| 84 | + |
| 85 | +_Possible mentors_: |
| 86 | + |
| 87 | +* Patrick Steinhardt < <[email protected]> > |
| 88 | + |
| 89 | + |
| 90 | +### Machine-Readable Repository Information Query Tool |
| 91 | + |
| 92 | +This project aims to create a new Git command dedicated to querying repository |
| 93 | +metadata and configuration in a structured, machine-readable format. Currently, |
| 94 | +much of this functionality exists within git-rev-parse(1), which has evolved |
| 95 | +beyond its original purpose. The new command will provide a cleaner, more |
| 96 | +focused interface for programmatically accessing repository information using |
| 97 | +JSON output. |
| 98 | + |
| 99 | +The student will design and implement this new command, focusing on identifying |
| 100 | +what repository information should be exposed, designing a consistent JSON |
| 101 | +schema, and implementing the necessary interfaces to Git's internal APIs. Key |
| 102 | +challenges include determining which subset of information from git-rev-parse to |
| 103 | +expose via this new command, ensuring backward compatibility, and creating a |
| 104 | +clean, well-documented command interface that's useful for scripts and tools. |
| 105 | + |
| 106 | +While this is an exploratory project that hasn't been extensively discussed in |
| 107 | +the Git community, it addresses a real need for better programmatic access to |
| 108 | +repository information. |
| 109 | + |
| 110 | +_Expected Project Size_: 175 hours or 350 hours |
| 111 | + |
| 112 | +_Difficulty_: Medium |
| 113 | + |
| 114 | +_Languages_: C, shell(bash) |
| 115 | + |
| 116 | +_Possible mentors_: |
| 117 | + |
| 118 | +* Patrick Steinhardt < <[email protected]> > |
0 commit comments