On Mon, Feb 5, 2024 at 9:39 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > Add project ideas for the GSoC 2024. > --- > > I came up with four different topics: > > - The reftable unit test refactorings. This topic can also be squashed > into the preexisting unit test topics, I wouldn't mind. In that case > I'd be happy to be a possible mentor, too. > > - Ref consistency checks for git-fsck(1). This should be rather > straight forward and make for an interesting topic. > > - Making git-bisect(1)'s state more self-contained as recently > discussed. This topic is easy to implement, but the backwards > compatibility issues might require a lot of attention. > > - Implementing support for reftables in the "dumb" HTTP protocol. It's > quite niche given that the dumb protocol isn't really used much > nowadays anymore. But it could make for an interesting project > regardless. > > It's hard to estimate for me whether their scope is either too small or > too big. So please feel free to chime in and share your concerns if you > think that any of those proposals don't make much sense in your opinion. Thanks a lot for these ideas! I have applied your patch and pushed it. I have a few concerns though, see below. > SoC-2024-Ideas.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 129 insertions(+) > > diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md > index 3efbcaf..286aea0 100644 > --- a/SoC-2024-Ideas.md > +++ b/SoC-2024-Ideas.md > @@ -39,3 +39,132 @@ Languages: C, shell(bash) > Possible mentors: > * Christian Couder < <christian.couder@xxxxxxxxx> > > > +### Convert reftable unit tests to use the unit testing framework > + > +The "reftable" unit tests in "t0032-reftable-unittest.sh" > +predate the unit testing framework that was recently > +introduced into Git. These tests should be converted to use > +the new framework. > + > +See: > + > + - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@xxxxxxxxxx/> > + > +Expected Project Size: 175 hours or 350 hours > + > +Difficulty: Low "Difficulty: Low" might not be very accurate from the point of view of contributors. I think it's always quite difficult to contribute something significant to Git, and sometimes more than we expected. > +Languages: C, shell(bash) > + > +Possible mentors: > +* Patrick Steinhardt < <ps@xxxxxx> > > +* Karthik Nayak < <karthik.188@xxxxxxxxx> > > + > +### Implement consistency checks for refs > + > +The git-fsck(1) command is used to check various data > +structures for consistency. Notably missing though are > +consistency checks for the refdb. While git-fsck(1) > +implicitly checks some of the properties of the refdb > +because it uses its refs for a connectivity check, these > +checks aren't sufficient to properly ensure that all refs > +are properly consistent. > + > +The goal of this project would be to introduce consistency > +checks that can be implemented by the ref backend. Initially > +these checks may only apply to the "files" backend. With the > +ongoing efforts to upstream a new "reftable" backend the > +effort may be extended. > + > +See: > + > + - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@xxxxxxx/ > + - https://lore.kernel.org/git/cover.1706601199.git.ps@xxxxxx/ > + > +Expected Project Size: 175 hours or 350 hours > + > +Difficulty: Medium > + > +Languages: C, shell(bash) > + > +Possible mentors: > +* Patrick Steinhardt < <ps@xxxxxx> > > +* Karthik Nayak < <karthik.188@xxxxxxxxx> > > + > +### Refactor git-bisect(1) to make its state self-contained > + > +The git-bisect(1) command is used to find a commit in a > +range of commits that introduced a specific bug. Starting a > +bisection run creates a set of state files into the Git > +repository which record various different parameters like > +".git/BISECT_START". These files look almost like refs > +due to their names being all-uppercase. This has led to > +confusion with the new "reftable" backend because it wasn't > +quite clear whether those files are in fact refs or not. > + > +As it turns out they are not refs and should never be > +treated like one. Overall, it has been concluded that the > +way those files are currently stored is not ideal. Instead > +of having a proliferation of files in the Git directory, it > +was discussed whether the bisect state should be moved into > +its own "bisect-state" subdirectory. This would make it more > +self-contained and thereby avoid future confusion. It is > +also aligned with the sequencer state used by rebases, which > +is neatly contained in the "rebase-apply" and "rebase-merge" > +directories. > + > +The goal of this project would be to realize this change. > +While rearchitecting the layout should be comparatively easy > +to do, the harder part will be to hash out how to handle > +backwards compatibility. > + > +See: > + > + - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/ >From reading the discussion it looks like everyone is Ok with doing this. I really hope that we are not missing something that might make us decide early not to do this though. > +Expected Project Size: 175 hours or 350 hours > + > +Difficulty: Medium > + > +Languages: C, shell(bash) > + > +Possible mentors: > +* Patrick Steinhardt < <ps@xxxxxx> > > +* Karthik Nayak < <karthik.188@xxxxxxxxx> >
