CINXE.COM

SoC 2025 Applicant Microprojects

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title>SoC 2025 Applicant Microprojects</title> <meta name="viewport" content="width=device-width"> <link rel="icon" type="image/x-icon" href="/images/logo.png"/> <link rel="stylesheet" href="/css/main.css"> <script src="/script/script.js" defer></script> <link rel="alternate" type="application/rss+xml" title="RSS" href="/feed.xml"> </head> <body> <div id="wrapper"> <div id="navbar" class="navbar"> <ul> <li><a href="/">Home</a> <li><a href="/rev_news/rev_news/">About Git Rev News</a> <li><a href="/rev_news/news_sources/">Git Rev News Sources</a> <li><a href="/rev_news/">Git Rev News</a> <li><a href="/rev_news/archive/">Git Rev News Archive</a> <li><a href="/SoC-2025-Microprojects/">SoC 2025 Applicant Microprojects</a> <li><a href="/SoC-2025-Ideas/">SoC 2025 Ideas</a> <li><a href="/SoC-2022-Org-Application/">SoC 2022 Organization Application</a> <li><a href="/Mentoring-Program-Guide/">Mentoring Program Guide</a> <li><a href="/Historical-SoC-Outreachy/">Historical Summer of Code and Outreachy Materials</a> <li><a href="/Hacking-Git/">Hacking Git</a> <li><a href="/General-Microproject-Information/">General Microproject Information</a> <li><a href="/General-Application-Information/">General Application Information</a> <li><a href="/GSoC-Participants/">GSoC participants</a> </ul> </div> <div class="site"> <div class="header"> <!-- nothing yet --> </div> <h2 id="introduction">Introduction</h2> <p>First make sure you read and understand <a href="https://git.github.io/General-Microproject-Information">our general guidelines and suggestions for microprojects</a>.</p> <p>There are some suggestions on how you can find some microprojects on your own in the document.</p> <h2 id="ideas-for-microprojects">Ideas for microprojects</h2> <h3 id="fix-sign-comparison-warnings-in-gits-codebase">Fix Sign Comparison Warnings in Git’s Codebase</h3> <p>Help improve Git’s code quality by fixing sign comparison warnings in files that currently disable these warnings. The goal is to remove instances of <code class="language-plaintext highlighter-rouge">DISABLE_SIGN_COMPARE_WARNINGS</code> macro and fix the underlying issues properly.</p> <h4 id="steps-to-complete">Steps to Complete</h4> <ol> <li>Find a C source file that contains <code class="language-plaintext highlighter-rouge">#define DISABLE_SIGN_COMPARE_WARNINGS</code></li> <li>Remove this #define</li> <li> <p>Build Git with <code class="language-plaintext highlighter-rouge">DEVELOPER=1</code> to enable compiler warnings. The <code class="language-plaintext highlighter-rouge">DEVLEOPER</code> can be specified in your <code class="language-plaintext highlighter-rouge">config.mak</code> or as follows</p> <div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>make <span class="nv">DEVELOPER</span><span class="o">=</span>1 <span class="nt">-j4</span> </code></pre></div> </div> </li> <li>Fix all <code class="language-plaintext highlighter-rouge">-Wsign-compare</code> warnings that appear for that file: <ul> <li>Pay attention to comparisons between signed and unsigned integers</li> <li>Modify variable types or add appropriate casts as needed</li> <li>Ensure the fixes don’t change the code’s behavior</li> </ul> </li> </ol> <h4 id="notes">Notes</h4> <ul> <li>Each file should be handled in a separate patch</li> <li>Follow Git’s commit message conventions</li> <li>Test your changes thoroughly</li> <li>This is part of an ongoing effort to enable <code class="language-plaintext highlighter-rouge">-Wsign-compare</code> globally</li> </ul> <h4 id="related-patches">Related Patches</h4> <p>For context on why this is a crucial improvement to Git’s codebase, checkout <a href="https://public-inbox.org/git/20241206-pks-sign-compare-v4-0-0344c6dfb219@pks.im/">this e-mail</a> by Patrick Steinhardt.</p> <h3 id="modernize-test-path-checking-in-gits-test-suite">Modernize Test Path Checking in Git’s Test Suite</h3> <p>Help improve Git’s test suite by converting old-style path checks to use modern helper functions. We’ll be replacing basic shell test commands like <code class="language-plaintext highlighter-rouge">test -f</code> with Git’s dedicated test helpers like <code class="language-plaintext highlighter-rouge">test_path_is_file</code>.</p> <h4 id="steps-to-complete-1">Steps to Complete</h4> <ol> <li>Find a test script using old-style path checks: <div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code>git <span class="nb">grep</span> <span class="s2">"test -[efd]"</span> t/ </code></pre></div> </div> </li> <li>Look for patterns like: <div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">test</span> <span class="nt">-f</span> path/to/file <span class="c"># old way</span> test_path_is_file path/to/file <span class="c"># new way</span> <span class="nb">test</span> <span class="nt">-d</span> some/directory <span class="c"># old way</span> test_path_is_dir some/directory <span class="c"># new way</span> </code></pre></div> </div> </li> <li>Important: Only replace checks that are actually testing for conditions, not those used in flow control. For example: <div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># DON'T change this - it's flow control</span> <span class="k">if </span><span class="nb">test</span> <span class="nt">-e</span> <span class="s2">"file.txt"</span><span class="p">;</span> <span class="k">then </span>do_something <span class="k">fi</span> <span class="c"># DO change this - it's a test assertion</span> <span class="nb">test</span> <span class="nt">-e</span> <span class="s2">"file.txt"</span> <span class="o">||</span> error <span class="s2">"file.txt should exist"</span> </code></pre></div> </div> </li> </ol> <h4 id="notes-1">Notes</h4> <ul> <li>Start small: Pick a test file with just a few instances to convert</li> <li>Run the test suite after your changes to ensure nothing breaks</li> <li>Follow Git’s commit message style</li> <li>Include which command you used to find the instances in your commit message</li> </ul> <h4 id="need-help">Need Help?</h4> <ul> <li>Reference <a href="https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/">this discussion</a> for detailed examples.</li> <li>If you can’t find any instances to fix, let us know what search command you used</li> </ul> <h3 id="add-more-builtin-patterns-for-userdiff">Add more builtin patterns for userdiff</h3> <p>“git diff” shows the function name corresponding to each hunk after the @@ … @@ line. For common languages (C, HTML, Ada, Matlab, …), the way to find the function name is built-in Git’s source code as regular expressions (see userdiff.c). A few languages are common enough to deserve a built-in driver, but are not yet recognized. For example, shell.</p> <p>This project requires a very good knowledge of regular expressions.</p> <p>It is easy though to find examples of how this can be done by searching the code base and the mailing list archive, as this has already been done for a number of languages.</p> <h3 id="replace-a-run_command-call-by-direct-calls-to-c-functions">Replace a run_command*() call by direct calls to C functions</h3> <p>See for example what Junio did in <a href="https://github.com/git/git/commit/ffcb4e94d3">ffcb4e94d3</a> (bisect: do not run show-branch just to show the current commit, 2021-07-27).</p> <p>If you can’t find one please tell us, along with the command you used to search, so that we can remove this microproject idea.</p> <h3 id="avoid-suppressing-gits-exit-code-in-test-scripts">Avoid suppressing <code class="language-plaintext highlighter-rouge">git</code>’s exit code in test scripts</h3> <p>The Git project uses a large collection of integration tests written in Shell to guard against regressions when adding new features or fixing bugs. The scripts in question can be found in the <code class="language-plaintext highlighter-rouge">t</code> directory <a href="https://github.com/git/git/tree/master/t">here</a>.</p> <p>While it is perfectly OK to use <a href="https://en.wikipedia.org/wiki/Pipeline_(Unix)">pipes</a> when writing integration tests, we must be careful to avoid writing a pipeline that suppresses the exit code of a Git process, like so:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>git &lt;subcommand&gt; | &lt;some other command&gt; </code></pre></div></div> <p>…since the exit code of <code class="language-plaintext highlighter-rouge">git &lt;subcommand&gt;</code> would be suppressed by the pipe. If <code class="language-plaintext highlighter-rouge">git &lt;subcommand&gt;</code> crashed, we would not catch it in the above example when running the integration suite.</p> <p>Other examples to avoid include:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># bad: &lt;some command&gt; $(git &lt;subcommand&gt;) # also bad: &lt;some command&gt; &lt;&lt;EOF ... some text ... $(git &lt;subcommand&gt;) EOF </code></pre></div></div> <p>…since the exit code of <code class="language-plaintext highlighter-rouge">git &lt;subcommand&gt;</code> is hidden behind the subshell in both instances.</p> <p>On the other hand, both of the following examples are OK, since neither hides the exit code of running <code class="language-plaintext highlighter-rouge">git &lt;subcommand&gt;</code>:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># good: var=$(git &lt;subcommand&gt;) # also good: &lt;some command&gt; | &lt;some other command&gt; | git &lt;subcommand&gt; </code></pre></div></div> <p>(provided that neither <code class="language-plaintext highlighter-rouge">&lt;some command&gt;</code> or <code class="language-plaintext highlighter-rouge">&lt;some other command&gt;</code> are <code class="language-plaintext highlighter-rouge">git</code>).</p> <p>See the commit <a href="https://github.com/git/git/commit/c6f44e1da5e88e34">c6f44e1da5</a> for example, and then do the same thing in one other test script.</p> <p>If you can’t find one please tell us, along with the command you used to search, so that we can remove this microproject idea.</p> <h3 id="use-unsigned-integral-type-for-collection-of-bits">Use unsigned integral type for collection of bits.</h3> <p>Pick one field of a structure that (1) is of signed integral type and (2) is used as a collection of multiple bits. Discuss if there is a good reason why it has to be a signed integral field and change it to an unsigned type otherwise. [<a href="https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com">thread</a>]</p> <p>Even though the amount of code to write is small, these projects involve a lot of prior work to understand the specification and deal with all potential corner-cases.</p> <h3 id="modernize-a-test-script">Modernize a test script</h3> <p>A number of our test scripts have been written a long time ago in a style that is now outdated.</p> <p>In the following email it is explained in details how to modernize and clean up the t7001 test script:</p> <p><a href="https://lore.kernel.org/git/CAPig+cQpUu2UO-+jWn1nTaDykWnxwuEitzVB7PnW2SS_b7V8Hg@mail.gmail.com/">https://lore.kernel.org/git/CAPig+cQpUu2UO-+jWn1nTaDykWnxwuEitzVB7PnW2SS_b7V8Hg@mail.gmail.com/</a></p> <p>t7001 is not the only test script where similar changes could be made though.</p> <p>Find one test script that needs some of the same changes and make them. Please make sure that the test script is not already being worked on by asking on the mailing list before starting to work on it.</p> <p>There should be only one kind of change per commit. For example if one of your commits indents test bodies with TABs, instead of spaces, then this should be the only kind of change in this commit.</p> <h4 id="notes-2">Notes</h4> <ul> <li>only work on <code class="language-plaintext highlighter-rouge">t/t????-*.sh</code> scripts.</li> <li>pick just one script (so as to avoid exhausting the pool for other candidates).</li> <li>When converting <code class="language-plaintext highlighter-rouge">test -[def]</code> to use <code class="language-plaintext highlighter-rouge">test_path_exists()</code> and cousins only convert instances which semantically are assertions (i.e. used as part of a &amp;&amp;-chain).</li> </ul> <div class="footer"> <!-- nothing yet --> </div> </div> <div id="menuLinkBar"><a href="#navbar">Menu</a></div> </div> <!-- Google Analytics snippet: --> <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-68655198-1', 'auto'); ga('send', 'pageview'); </script> </body> </html>

Pages: 1 2 3 4 5 6 7 8 9 10