diff --git a/GSoC-Participants.md b/GSoC-Participants.md new file mode 100644 index 0000000000..d9a68bf751 --- /dev/null +++ b/GSoC-Participants.md @@ -0,0 +1,211 @@ +--- +layout: default +title: GSoC participants +--- + +This document collects the list of contributors who've contributed +to Git via GSoC. + + + +### 2025 + +1. Ayush Chandekar [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) ] [ [final report](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html) ] [ [blog](https://ayu-ch.github.io/) ] +2. Lucas Seiki Oshiro [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) ] [ [final report](https://lucasoshiro.github.io/gsoc-en/#final-report) ] [ [blog](https://lucasoshiro.github.io/gsoc-en/#weeks) ] +3. Meet Soni [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) ] [ [final report](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/) ] [ [blog](https://inosmeet.github.io/posts/gsoc25/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/programs/2025/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2025/05/31/edition-123/) + +### 2024 + +1. Jialuo She [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) ] [ [final report](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) ] [ [blog](https://luolibrary.com/) ] +2. Ghanshyam Thakkar [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/e9C4rhrv) ] [ [final report](https://spectre10.github.io/posts/gsoc_final_report/) ] [ [blog](https://spectre10.github.io/) ] +3. Chandra Pratap [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/tlh611d7) ] [ [final report](https://chand-ra.github.io/2024/08/24/GSoC-Final-Report.html) ] [ [blog](https://chand-ra.github.io/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2024/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2024/05/31/edition-111/) + +### 2023 + +1. Shuqi Liang [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/Rkbc1Abe) ] [ [final report](https://cheskaqiqi.github.io/2023/08/22/Final/) ] [ [blog](https://cheskaqiqi.github.io/tags/GSoC/) ] +2. Kousik Sanagavarapu [ [project](https://summerofcode.withgoogle.com/archive/2023/projects/rck3kmq2) ] [ [final report](https://five-sh.github.io/2023/08/26/the-final-report) ] [ [blog](https://five-sh.github.io/blog) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2023/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2023/06/30/edition-100/) + +### 2022 + +1. Shaoxuan Yuan [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/hz4rcOUB) ] [ [final report](https://ffyuanda.github.io/blog/GSoC-final-blog/) ] [ [blog](https://ffyuanda.github.io/tags/#learn) ] +2. Abhradeep Chakraborty [ [project](https://summerofcode.withgoogle.com/archive/2022/projects/UPtA6qdf) ] [ [final report](https://medium.com/@abhra303/gsoc-final-report-feaaacfae737) ] [ [blog](https://medium.com/@abhra303) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2022/organizations/git) +- [Rev News article](https://git.github.io/rev_news/2022/06/30/edition-88/) + + +### 2021 + +1. ZheNing Hu [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5443907994779648) ] [ [final report](https://github.com/adlternative/adlternative.github.io/blob/gh-pages/blogs/gsoc/GSOC-Git-Final-Blog.md) ] [ [blog](https://github.com/adlternative/adlternative.github.io/tree/gh-pages/blogs/gsoc/) ] +2. Atharva Raykar [ [project](https://summerofcode.withgoogle.com/archive/2021/projects/5071550033690624) ] [ [final report](https://github.com/tfidfwastaken/gitnotes/blob/main/final-report.md) ] [ [blog](https://github.com/tfidfwastaken/gitnotes/tree/main) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2021/organizations/6398200235163648) +- [Rev News article](https://git.github.io/rev_news/2021/05/27/edition-75/) + + +### 2020 + +1. Shourya Shukla [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/4541259818991616) ] [ [final report](https://shouryashukla.blogspot.com/2020/08/the-final-report.html) ] [ [blog](https://shouryashukla.blogspot.com/search/label/GSoC) ] +2. Abhishek Kumar [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6510085276172288) ] [ [final report](https://github.com/abhishekkumar2718/GSoC20/blob/master/README.md) ] [ [blog](https://abhishekkumar2718.github.io/gsoc/) ] +3. Hariom Verma [ [project](https://summerofcode.withgoogle.com/archive/2020/projects/6123927484497920) ] [ [final report](https://harry-hov.github.io/blogs/posts/the-final-report) ] [ [blog](https://harry-hov.github.io/blogs/posts/) ] + + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2020/organizations/5445576591671296) +- [Rev News article](https://git.github.io/rev_news/2020/05/28/edition-63/) + + +### 2019 + +1. Rohit Ashiwal [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/5390155215536128) ] [ [final report](https://web.archive.org/web/20210727190950/https://rashiwal.me/2019/final-report/) ] [ [blog](https://web.archive.org/web/20210515085551/https://rashiwal.me/) ] +2. Matheus Tavares [ [project](https://summerofcode.withgoogle.com/archive/2019/projects/4787791739748352) ] [ [final report](https://matheustavares.gitlab.io/posts/gsoc-final-report) ] [ [blog](https://matheustavares.gitlab.io/tags/git/) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2019/organizations/6548634445807616) +- [Rev News - May 2019](https://git.github.io/rev_news/2019/05/22/edition-51/) + + +### 2018 + +1. Pratik Karki [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/5389615745728512) ] [ [final report](https://github.com/prertik/GSoC2018?tab=readme-ov-file) ] [ [blogs](https://prertik.github.io/categories/git/) ] +2. Paul-Sebastian Ungureanu [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6700324135895040) ] [ [final report and blogs](https://github.com/ungps/gsoc2018?tab=readme-ov-file) ] +3. Alban Gruin [ [project](https://summerofcode.withgoogle.com/archive/2018/projects/6165469845258240) ] [ [final report](https://github.com/agrn/gsoc2018?tab=readme-ov-file) ] [ [blogs](https://blog.pa1ch.fr/category/gsoc-2018.html) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2018/organizations/4840889583140864) +- [Rev News - May 2018](https://git.github.io/rev_news/2018/05/16/edition-39/) + +### 2017 + +1. Prathamesh Chavan [ [project](https://summerofcode.withgoogle.com/archive/2017/projects/5434523185577984) ] [ [final report](https://docs.google.com/document/d/1RmUvJBf4x8TI71Fltg8xWP-s7zkhz3bGPyEJMgRx91Y/edit#heading=h.5r7i4cugqwi3) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2017/organizations/5061577619275776) +- [Rev News - Oct 2017](https://git.github.io/rev_news/2017/10/11/edition-32/) + +### 2016 + +1. Pranit Bauva [ [project](https://summerofcode.withgoogle.com/archive/2016/projects/5595001820020736) ] [ [final report](https://docs.google.com/document/d/1Uir0a8cRYlWANuzoU4iTDtEvPukvtTJcC_dB3KJUgqM/edit#heading=h.mipx2w79za4f) ] + +#### References + +- [GSoC archive](https://summerofcode.withgoogle.com/archive/2016/organizations/5532648021688320#projects-list) +- [Rev News - Oct 2016](https://git.github.io/rev_news/2016/09/14/edition-19/) + +### 2015 + +1. Karthik Nayak [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/karthiknayak94.html) ] [ [fork](https://github.com/KarthikNayak/git) ] [ [a mailing list mail](https://public-inbox.org/git/553F7A50.1080907@gmail.com/) ] +2. Paul Tan [ [project](https://www.google-melange.com/archive/gsoc/2015/orgs/git/projects/pyokagan.html) ] [ [fork](https://github.com/pyokagan/git) ] [ [a mailing list mail](https://public-inbox.org/git/CACRoPnQ5_r-26J4gBHc27KZt3X9KAU7eFkA3vz_GE6_dP-Uyug@mail.gmail.com/) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2015/orgs/git) +- [Rev News - May 2015](https://git.github.io/rev_news/2015/05/13/edition-3/#other-news) + +### 2014 + +1. Tanay Abhra [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/tanayabh.html) ] +2. Fabian Ruch [ [project](https://www.google-melange.com/archive/gsoc/2014/orgs/git/projects/bafain.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2014/orgs/git) +- [GSoC retrospective](https://public-inbox.org/git/vpqsik1yg1l.fsf@anie.imag.fr/) + + +### 2013 + +***Did not participate*** + + +### 2012 + +1. Thomas Gummerer [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/tgummerer.html) ] +1. Michael Schubert [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/schu.html) ] +1. Florian Achleitner [ [project](https://www.google-melange.com/archive/gsoc/2012/orgs/git/projects/flyingflo.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2012/orgs/git) + + +### 2011 + +1. Carlos Martín Nieto [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/carlosmn.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/artagnon.html) ] +1. Fredrik Gustafsson [ [project](https://www.google-melange.com/archive/gsoc/2011/orgs/git/projects/iveqy.html) ] + + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2011/orgs/git) + + +### 2010 + +1. Vicent Marti [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/tanoku.html) ] +1. Ramkumar Ramachandra [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/artagnon.html) ] +1. Bo Yang [ [project](https://www.google-melange.com/archive/gsoc/2010/orgs/git/projects/struggleyb.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2010/orgs/git) + +### 2009 + +1. Nick Edelen [ [project](https://www.google-melange.com/archive/gsoc/2009/orgs/git/projects/sirnot.html) ] + +#### References + +- [GSoC archive](https://www.google-melange.com/archive/gsoc/2009/orgs/git) + + +### 2008 + +1. Joshua Roys (_project_: GitTorrent) [ [final e-mail](https://lore.kernel.org/git/48C05FB5.3010901@gmail.com/) ] +2. Sverre Rabbelier (_project_: git-statistics) [ [final e-mail](https://lore.kernel.org/git/bd6139dc0809041544o427356c9i40a28b1c182817eb@mail.gmail.com/) ] +3. Lea Wiemann (_project_: Gitweb caching) [ [idea discussion](https://lore.kernel.org/git/483C4CFF.2070101@gmail.com/#t) ] +4. Marek Zawirski (_project_: Eclipse plugin push support) [ [final e-mail](https://lore.kernel.org/git/48C564ED.7050402@gmail.com/) ] +5. Miklos Vajna (_project_: git-merge builtin) [ [final e-mail](https://lore.kernel.org/git/20080904225559.GP16514@genesis.frugalware.org/) ] +6. Stephan Beyer (_project_: git-sequencer) [ [final e-mail](https://lore.kernel.org/git/20080904223653.GA15170@leksak.fem-net/) ] + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2008?csw=1#git-development-community) +- [Mail about GSoC participant summary](https://lore.kernel.org/git/200809042315.58898.jnareb@gmail.com/) +- [GSoC selection summary](https://lore.kernel.org/git/20080422013201.GA4828@spearce.org/) + + +### 2007 + +1. Carlos Rica (_project_: Shell script to C builtin conversions) +2. Luiz Capitulino (_project_: Libification) + +#### References + +- [GSoC archive](https://developers.google.com/open-source/gsoc/2007?csw=1#git-development-community) +- [GSoC report](https://lore.kernel.org/git/20070903034201.GP18160@spearce.org/) diff --git a/Gemfile b/Gemfile index 7d8bf5df60..3cc8ef00a1 100644 --- a/Gemfile +++ b/Gemfile @@ -5,3 +5,4 @@ gem 'github-pages', group: :jekyll_plugins # gem "webrick", "~> 1.7" # N.B. we may not want to fix this Gemfile to Ruby 3 gem "webrick" +gem 'jekyll-redirect-from' \ No newline at end of file diff --git a/General-Application-Information.md b/General-Application-Information.md index 54b275c28c..7a2402b95d 100644 --- a/General-Application-Information.md +++ b/General-Application-Information.md @@ -9,7 +9,9 @@ programs can get information about what the Git project would like to see in an application. *Please read this page completely before focusing on a project or a - microproject ideas, or microproject general information.* + microproject ideas, or microproject general information. + Specifically, also read the "AI guidelines" section to know our + stance regarding the usage of AI tools.* ## Microproject (required) @@ -66,6 +68,13 @@ does [Junio's "What's cooking in git.git" emails](https://lore.kernel.org/git/?q say about it? In general it's a good idea to describe all your Git related work so far with a good amount of detail. +If the mentoring program allows different project "sizes", like for +example 'Small', 'Medium' and 'Large', or different project +"duration", like from 12 weeks to 22 weeks, please tell us in you +application which project size or duration you prefer. It's usually +not difficult for us to adapt a project we propose to different sizes +or durations. + Applicants must send drafts of their proposal on the mailing-list before submitting it officially to GSoC or Outreachy to get feedback from the community. They are strongly encouraged to publish a draft on @@ -123,50 +132,154 @@ are interested in, it is a good idea to: used for searching the mailing list and linking to previous discussions.) +## AI guidelines + +The use of Artificial Intelligence related tools ("AI" or "AIs" for +short), like Large Language Models ("LLMs"), by developers is becoming +more and more popular, but that's not a reason to blindly use them, +especially when working on the Git project. + +### Legal issues + +In general, it's not clear if AI generated code or documentation are +acceptable in the Git project. Authors contributing to Git are +required to "sign off" the patches they contribute, and to agree with +the Developer’s Certificate of Origin, also called DCO, (see +), while the DCO +says basically that authors of a patch should be sure about the origin +of its content. + +As we cannot usually be sure how AIs have been trained and that they +are not just repeating proprietary existing code or documentation they +saw during their training, we cannot accept much AI generated code or +documentation in general. Now, if it's only a few lines to fix a bug +or to implement a common pattern or summarize something, and if that +looks specific enough to a current concrete problem a developer is +working on, that might be OK. + +Anyway as the situation is not clear for the Git project and probably +many other open source projects, you should be very prudent regarding +this. + +### Be very careful with AI output + +For a number of reasons, not just legal ones, developers should really +make sure that they treat what AIs produce very carefully. They +should: + + - triple check everything, especially regarding our guidelines + (indent, style, commit message guidelines, etc, see especially the + SubmittingPatches and CodingGuidelines docs as well as the other + pages on this website) and the feedback reviewers already gave + them or others, + + - build and test changes, using existing, new or manual tests, to + check that the changes are correct, perform well and don't produce + garbage output, + + - doubt anything they don't fully understand, or anything that might + not match our guidelines or feedback, and + + - fix, simplify, adapt, reword or change anything that is + suspicious, bloated, too formal, or that they don't understand, or + that doesn't match our guidelines or our feedback. + +Yeah, AIs still often hallucinate or just produce bad code, commit +messages, documentation or output, even when you point out their +mistakes. + +### We don't accept AI output as-is + +It's unacceptable to send us something that is obvious AI slop, or +that sounds overly formal or bloated, or that looks good on the +surface but makes no sense, or that senders don’t understand or cannot +explain. It just wastes our time and we cannot accept it. We want to +interact with and mentor humans, not AIs. + +For example, it's unacceptable to have an AI generate a commit message +where it just describes what the code in the commit does, instead of +the purpose of the change, and then send that to us. + +In general, it's unacceptable to send AI-generated patches or messages +as-is to the mailing list or to mentors' or developers' personal email +addresses. We won't consider candidates doing that. + +For another, unfortunately common, example, it's unacceptable to send +us an application that has obviously been AI generated and doesn't +follow our guidelines or the feedback we previously gave to other +applicants. Those applications will be dropped. + +### Blindly using AI is far worse than not applying + +As bad AI use is growing in general, not just to apply to mentoring +programs, more and more tools and ways are being developed to find out +and fight against bad AI use. + +So people who apply by sending us AI generated output as-is, not only +waste their time, and our time, for no result, but they also leave +evidence on our mailing list archive of their bad behavior. + +For example, employers already use social media screening tools or +candidate assessment software when hiring people, and it's likely that +those tools, which often already use AI, are, or will be able to find +out soon about such bad behavior. + +### Better ways to use AIs + +Developers would often likely get better results, learn more and have +a better overall experience by asking AIs to only explain things, and +guide them step by step towards producing a solution by themselves, +rather than by asking for a full solution that they would then mostly +copy-paste. + +They can also use AIs to help with debugging, or with checking for +obvious mistakes, things that can be improved, things that don't match +our style, guidelines or our feedback, before sending it to us. + ## Note about the number of slots The Git organization usually has very limited mentoring capacity. -These days we usually accept around 2 or 3 students per season -(Winter or Summer). +These days we usually accept between around 1 to 3 GSoC contributors +(in the Summer) or Outreachy interns (in the Winter). ## Note about giving back and mentoring -We appreciate very much students and interns who stay around after the -mentoring period is over. It is very nice to see them on the mailing -list, even if they don't contribute much. It's of course better when -they continue to contribute though, even by just reviewing a patch -from time to time. +We appreciate very much GSoC contributors and Outreachy interns who +stay around after the mentoring period is over. It is very nice to see +them on the mailing list, even if they don't contribute much. It's of +course better when they continue to contribute though, even by just +reviewing a patch from time to time. Some people have been around for more than 10 years, others have become regular contributors and that's great! One very nice way to contribute and to give back is to mentor or -co-mentor other students or interns coming after you. It helps create -more opportunities for more students and interns like you, as -mentoring capacity is the main factor preventing us from accepting -more students and interns. If each student or intern accepted to -co-mentor twice (for example once in Summer and once in Winter) just -after they have been mentored, our mentoring capacity could increase -significantly each year. - -Even though successful former students/interns usually have adequate -technical ability to be a successful mentor, unfortunately few of them -have been willing to just co-mentor once along with an experienced -mentor. +co-mentor other contributors or interns coming after you. It helps +create more opportunities for more contributors and interns like you, +as mentoring capacity is the main factor preventing us from accepting +more contributors and interns. If each contributor or intern accepted +to co-mentor twice (for example once in the Summer and once in the +Winter) just after they have been mentored, our mentoring capacity +could increase significantly each year. + +Even though successful former contributors/interns usually have +adequate technical ability to be a successful mentor, unfortunately +few of them have been willing to just co-mentor once along with an +experienced mentor. Other free or open source projects have done better than us on this. At the Google Summer of Code Mentor Summit for example, more -than 30% of the mentors were former students. +than 30% of the mentors are usually former contributors. Here is a quote by a mentor (Carlos Fernandez Sanz) on the GSoC Mentors List, that describes very well how we see GSoC and Outreachy: "GSoC is (for us, anyway) more about growing the community than getting stuff done. If they don't stick around their value diminishes -a lot, even if they do a great job [...]. The students that did a -great job but completely left the community [...] are just a memory... -the ones that have been with us and that are now mentors [...], long -after they participated in GSoC, are the ones we love :-)" +a lot, even if they do a great job [...]. The [contributors] that did +a great job but completely left the community [...] are just a +memory... the ones that have been with us and that are now mentors +[...], long after they participated in GSoC, are the ones we love :-)" Consider showing us in your application previous mentoring, giving back and community activities that you have done, especially related @@ -180,21 +293,22 @@ Refactoring projects are usually easier to do step by step, and to get code merged step by step which is encouraging. In general refactoring projects are worthwhile to do even if the -project is not finished at the end of the GSoC and even if the student -or intern stops contributing after that. In those cases it is often a -good idea to later finish the refactoring either by ourselves or by -proposing it to another GSoC student or Outreachy intern. This way the -work of both students and mentors is not likely to be wasted. +project is not finished at the end of the GSoC and even if the +contributor or intern stops contributing after that. In those cases it +is often a good idea to later finish the refactoring either by +ourselves or by proposing it to another GSoC contributor or Outreachy +intern. This way the work of contributors, interns and mentors is not +likely to be wasted. With a project that implements a feature, there is a risk, if it's too complex or too difficult, that the feature will not be finished and that nothing, or nearly nothing, will have been merged during the GSoC or Outreachy internship. There is also the risk that another way to implement the feature will appear later in the GSoC or Outreachy -internship, and all, or nearly all, the work of the student or intern -and mentors will have been mostly wasted. It could also appear that -the use cases the feature was envisioned to be used in, are better -addressed by other improvements or a different workflow. +internship, and all, or nearly all, the work of the contributor or +intern and mentors will have been mostly wasted. It could also appear +that the use cases the feature was envisioned to be used in, are +better addressed by other improvements or a different workflow. Another potential issue is that a new feature might be prone to naming or user interface discussions which could last for a long time or @@ -239,7 +353,7 @@ earlier than you. This means that you might have to find a project idea that we haven't proposed in our idea list. The good side of this is that this project idea along with your -enthousiasm for it and the skills you show might encourage Git +enthusiasm for it and the skills you show might encourage Git developers to mentor you even if they weren't planning to mentor in the first place. It could also happen that someone, who was only planning to co-mentor, could agree to fully mentor you alone. diff --git a/General-Microproject-Information.md b/General-Microproject-Information.md index 2f1be88b9f..c98caeab81 100644 --- a/General-Microproject-Information.md +++ b/General-Microproject-Information.md @@ -9,7 +9,8 @@ It is strongly recommended that people who want to apply to the Git project for the Google Summer of Code (GSoC), Outreachy, or other such mentoring programs, called "applicants" in this document, submit a small code-related patch to the Git project as part of their -application. +application. We call the whole process of submitting such a small +code-related patch a "microproject". People who want to get involved in Git development outside mentoring programs can also benefit from information on this page to get @@ -17,6 +18,12 @@ started, though it might be a bit less relevant to them. If they want, they can use something like "[FirstTimer]", "[Newbie]", "[Newcomer]" instead of "[GSoC]" or "[Outreachy]" in the emails they send. +Anyway if you want to work on a microproject, or more generally if you +want to start getting involved in Git development, please read on +*all* the rest of this page. + +## What is a microproject? + Think of these microprojects as the "Hello, world" of getting involved with the Git project; the coding aspect of the change can be almost trivial, but to make the change the applicant has to become familiar @@ -32,28 +39,29 @@ well using the Git development process. It is *expected* that what you send will need several rounds of reviews and discussions. If you are not sure at all about a patch you -can put "[GSoC][RFC/PATCH]" or "[Outreachy][RFC/PATCH]", depending on -the mentoring program you are applying for, at the beginning of its -subject. +can mark it as RFC in the subject. See [section below](#use-a-tag-like-gsoc-outreachy-etc-in-your-subject) +about how to mark patches as RFC. -Consider [a sample email thread](http://public-inbox.org/git/1386590745-4412-1-git-send-email-t.gummerer@gmail.com/T/#u), +Consider [a sample email thread](https://public-inbox.org/git/1386590745-4412-1-git-send-email-t.gummerer@gmail.com/T/#u), which shows how a developer proposed a change and a patch to implement it. The problem being solved, the design of the proposed solution, and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC contributor, or Outreachy intern, you will be playing the role of the developer and engaging in a -similar discussion. Get familar with the flow, need for clarity on -both sides (i.e. you need to clearly defend your design, and need to +similar discussion. Get familiar with the flow, need for clarity on +both sides (i.e. you need to clearly explain your design, and need to ask for clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the discussion, to learn what is expected of you. +## Summary of the steps needed to complete a microproject + To complete a microproject, you will have to go through approximately the following steps: * Download the source code: clone the repository using the - [Git via Git](http://git-scm.com/downloads) instructions and read + [Git via Git](https://git-scm.com/downloads) instructions and read the `README` file. * Build the source code: this is described in the file `INSTALL`. @@ -66,13 +74,13 @@ the following steps: described in `Documentation/SubmittingPatches`. A more detailed step-by-step guide could be found in [`Documentation/MyFirstContribution.txt`](https://git-scm.com/docs/MyFirstContribution). -* The "[Hacking Git](https://git.github.io/Hacking-Git/)" page +* The "[Hacking Git](/Hacking-Git/)" page could also serve as a handy resource. It points to resources on various topics related to working on Git. * Select a microproject and check that it has not yet been taken or - discussed by searching the mailing list. - [Public Inbox](http://public-inbox.org/git/) is your friend. + discussed by searching the mailing list. Please read all the + sections below related to finding or selecting a microproject. * Send an email to the mailing list where you describe the microproject you want to work on, the way you want to do it, and @@ -89,7 +97,7 @@ the following steps: * Commit your change. Surprise: we use Git for that, so you will need to gain at least - [a basic familiarity](http://git-scm.com/documentation) with using + [a basic familiarity](https://git-scm.com/docs) with using Git. Make sure to write a good commit message that explains the reason for the change and any ramifications. You can find information on writing a good commit message in the @@ -97,29 +105,32 @@ the following steps: Remember to make sure that you agree with our "Developer's Certificate of Origin" (whose text is contained in `Documentation/SubmittingPatches`), and to - signify your agreement by adding a `Signed-off-by` line. + signify your agreement by adding a `Signed-off-by` line. Instructions + on how to add the sign-off is covered in the `SubmittingPatches` + document. * *Optional, but recommended:* - With an account at GitHub, you can use GitHub CI to test your changes + + With an account at GitHub or GitLab, you can use the CI to test your changes on Linux, Mac and Windows. See - [examples](https://github.com/git/git/actions/workflows/main.yml) - of recent CI runs. + [GitHub exmamples](https://github.com/git/git/actions/workflows/main.yml), [GitLab examples](https://gitlab.com/git-scm/git/-/pipelines) of recent CI runs. - To run these tests against your own branch, - [create a fork](https://help.github.com/articles/fork-a-repo/) - of [Git](https://github.com/git/git) on GitHub and switch to it. At the + To run these tests against your own branch: + * **GitHub**: [create a fork](https://help.github.com/articles/fork-a-repo/) of [Git](https://github.com/git/git) on GitHub and switch to it. At the top bar select [Actions tab](https://github.com/git/git/actions) and perform the initial setup to enable it for your fork. After enabling it, CI will run for a specific branch of your fork whenever you push new changes to it in GitHub. You can monitor the test state of all your branches in the same [Actions tab](https://github.com/git/git/actions) of your fork. + * **GitLab**: [create a fork](https://docs.gitlab.com/user/project/repository/forking_workflow/#create-a-fork) of [Git](https://gitlab.com/git-scm/git) on GitLab and switch to it. CI will run for a specific branch of your fork whenever you push new changes + to it in GitHub. You can monitor the test state of all your branches in the [Build > Pipeline](https://gitlab.com/git-scm/git/-/pipelines) section of your fork. If a branch did not pass all test cases then it is marked with a red cross. In that case you can click on the failing job and navigate to - "ci/run-build-and-tests.sh" and/or \ - "ci/print-test-failures.sh". You can also + `ci/run-build-and-tests.sh` and/or \ + `ci/print-test-failures.sh`. You can also download "Artifacts" which are tarred (or zipped) archives with test data - relevant for debugging. Fix the problem and push your fix to your GitHub fork. + relevant for debugging. Fix the problem and push your fix to your fork. This will trigger a new CI build. Ensure all tests pass. * Submit your change to the Git mailing list. For this step you @@ -131,8 +142,8 @@ the following steps: [submitGit](https://submitgit.herokuapp.com/). When you submit your patch, please mention that you plan to apply - for the GSoC or Outreachy. You can use "[GSoC][PATCH ...]" or - "[Outreachy][PATCH ...]" in the subject of the emails you send for + for the GSoC or Outreachy. You can use "[GSoC PATCH ...]" or + "[Outreachy PATCH ...]" in the subject of the emails you send for that purpose. This will ensure that we take special care not to overlook your application among the large pile of others. @@ -156,18 +167,28 @@ Applicants please attempt only **ONE** microproject. We want quality, not quantity! (Also, it takes work to collect the ideas, and it would be nice to have enough microprojects for everybody.) +### Change only a few files + This means that for a microproject that consists in refactoring or rewriting a small amount of code, your patch should change only **ONE** file, or perhaps 2 files if they are closely related, like "foo.c" and "foo.h". If you change a test file, the title of your patch (after the -"[GSoC][PATCH ...]" or "[Outreachy][PATCH ...]" part) should start +"[GSoC PATCH ...]" or "[Outreachy PATCH ...]" part) should start with "tXXXX: " where tXXXX is the start of the filename of the test script you change. If you change "foo.c" or "foo.h", the title of your patch should probably start with "foo: ". -In general it's a good idea to check on the mailing list archive what +If you create a function to refactor existing code, it's possible that +more files would be changed, but the changes should be trivial in most +of them. + +### Research existing related work + +In general it's a good idea to check on the mailing list archive +([lore.kernel.org](https://lore.kernel.org/git/) and +[Public Inbox](https://public-inbox.org/git/) are your friends) what other GSoC or Outreachy applicants attempting a microproject have already been told this year or any previous year, as hopefully it will help you avoid some mistakes. As some microproject ideas haven't @@ -181,6 +202,8 @@ problems when working on your real GSoC or Outreachy project. So it's a very good thing to show that you have researched your microproject and taken into account what you have found. +### After it's done, work on different things + If you've already done a microproject and are itching to do more, then get involved in other ways, like finding and fixing other problems in the code, or improving the documentation or code comments, or helping @@ -189,17 +212,36 @@ questions on the mailing list or in IRC, or writing new tests, etc., etc. In short, start doing things that other Git developers do! Alternatively you can of course focus on your project proposal. -## How to find other ideas for microprojects +## Be very careful when using AI tools + +There is an "AI guidelines" section on our +General-Application-Information page: + +https://git.github.io/General-Application-Information/ + +Please read it and make sure you use AI very carefully. + +## How to find ideas for microprojects First check the specific page(s) or information about Git microprojects related to your program that should have been published on this site or on the GSoC or Outreachy site. But then still read on everything below! -Any small code-related change would be suitable. Just remember to keep -the change small! It is much better for you to finish a small but -complete change than to try something too ambitious and not get it -done. +It's also possible that we haven't taken the time to put up a page +listing microprojects ideas for your program. The pages we used to +create for that were named "XXXX Applicant Microprojects" where XXXX +is the program name and a date, for example "SoC 2016 Applicant +Microprojects" for the GSoC in 2016, or "Outreachy Winter 2021-2022 +Applicant Microprojects" for Outreachy in 2021-2022. See the following +directory to find these old pages that might still be useful: + +https://git.github.io/Historical-SoC-Outreachy/ + +Any small code-related change would be suitable for a +microproject. Just remember to keep the change small! It is much +better for you to finish a small but complete change than to try +something too ambitious and not get it done. Though we don't require that your patch be accepted into the "master" branch by the time of your formal application, we still expect that a @@ -271,6 +313,11 @@ list. In general it's a very good idea to check that you can reproduce the bug on the latest version of Git before working on it. +Also some bugs are difficult to understand and require too much or too +difficult work for a microproject, so don't spend too much time on +them if it appears that they might not be simple to fix, and don't +hesitate to ask on the mailing list if they are a good microproject. + ### Searching for #leftoverbits in the mailing list People have recently started to add "#leftoverbits" to their emails @@ -284,6 +331,9 @@ But don't forget to search to check if what you find has already been addressed. If it has not been addressed, please ask first on the mailing list if it's a good idea to work on that. +As for bugs, and many things really, you can also ask if you are not +sure it's simple enough to fix. + ### Searching the code base itself Your best bet is probably to search for strings like "FIXME", "TODO", @@ -326,14 +376,53 @@ to"... It's likely that you will introduce yourself to the community around the same time you are going to start working on a micro-project. +### Tell us about you, or not + We don't require you to send us a special introductory email or to tell us about your skills, interests, experience, background, etc. Feel free to tell us what you want about yourself if you wish though. -But please, make it clear that you are interested in a specific -mentoring program and use the right tag, like [GSoC], [Outreachy], etc -at the beginning of the subject of your emails. +Make sure to specify your mentoring program clearly as +[suggested below](#use-a-tag-like-gsoc-outreachy-etc-in-your-subject). + +### Thoroughly check your eligibility in the program + +Before you introduce yourself, it's very important that you thoroughly +check as soon as possible that you are eligible for the mentoring +program you are interested in. + +This is especially important for Outreachy, which has strict rules and +is enforcing them. Their rules are available on: + +https://www.outreachy.org/docs/applicant/#eligibility + +Especially if you are a student, please check the section about the +rules for students, and especially check this one: + +"University students must have 42 consecutive days free from school +and exams during the internship period." + +The Outreachy organizers will check this rule with your university. +They will disqualify you if there is any requirement, especially this +one, that you don't meet. + +If you start applying to the Git project, this will deter others from +applying. We usually have very few projects and can only accept very +few applicants. So if others want to apply, they know they will have +to compete with you and possibly others, and they might prefer to find +another project with less competition. + +It happened recently that only two people applied for a project we +proposed, and both were later found to not be eligible because of +their university requirements. So in the end, we couldn't mentor +anyone for the project we proposed, which is bad for everyone. + +So please thoroughly check your eligibility before introducing +yourself, and please confirm in your introduction that you have +checked all the requirements and that you indeed meet them all. + +### Don't ask us to find a micro-project for you As we usually don't know your interests, skills, experience, background, etc, it's hard for us to select a micro-project for @@ -341,6 +430,8 @@ you, and it's part of your job as an applicant to research a good micro-project for you. It will show us that you will be able to select a good project for you and properly research it. +### Do ask for help, but be specific + You can ask for help if there are things you don't understand in a micro-project description, or if you have some trouble working on your micro-project or even finding a micro-project. But please be very @@ -400,6 +491,27 @@ other applicants or contributors participating in GSoC or Outreachy have been doing in the past, for example what kind of microproject they have chosen, how their proposal looked like, etc. +If you're using `format-patch` for sending your patches to the mailing list, +you can add this tag as follows: + +``` +git format-patch --subject-prefix='GSoC PATCH' + +(or) + +git format-patch --subject-prefix='Outreachy PATCH' +``` + +If you want to mark your patch as RFC, use + +``` +git format-patch --rfc --subject-prefix='GSoC PATCH' + +(or) + +git format-patch --rfc --subject-prefix='Outreachy PATCH' +``` + ### Reply inline Many people these days use the "top posting" posting style, but we @@ -460,10 +572,14 @@ or another pronoun to talk about you. Programs like Outreachy or GSoC usually have requirements for applicants. Sometimes applicants have to be accepted by the program -after they have shown they satisfy the requirements. +organizers after they have shown they satisfy the requirements. + +In any case it's interesting for us and others to know soon how you +currently stand regarding the requirements and maybe the acceptance +process. -In any case it's interesting for us to know soon how you currently -stand regarding the requirements and maybe the acceptance process. +See also the "Thoroughly check your eligibility in the program" +section above. ### Tell us what steps you have already taken diff --git a/Hacking-Git.md b/Hacking-Git.md index d8fe547873..7dd16d6658 100644 --- a/Hacking-Git.md +++ b/Hacking-Git.md @@ -3,12 +3,15 @@ layout: default title: Hacking Git --- -The goal of this document is not to be a tutorial, but rather to -point to interesting material that has already been written. +The goal of this document is not to be a tutorial, but rather to point +to interesting material that has already been written. -The goal is also not to list all the articles about Git or its -internals. There are a lot of good resources, including free -[books](http://git-scm.com/book/en/v2/), about that elsewhere. +The goal is also not to list all the articles, tools or resources +about Git or its internals. There are a lot of good resources, +including [free books](http://git-scm.com/book/en/v2/), and the +[archive of our newsletter](https://git.github.io/rev_news/archive/), +about that elsewhere. So on this page we focus on what is the most +interesting for developers starting to work on Git. Contributions are welcome though! Please contact us on the Git Mailing list (at [git@vger.kernel.org](mailto:git@vger.kernel.org)) or open an @@ -18,7 +21,9 @@ suggest improvements. Thanks! ## Building Git -* ["`INSTALL`"](https://github.com/git/git/blob/master/INSTALL) +* ["`INSTALL`"](https://github.com/git/git/blob/master/INSTALL) to build using [Make](https://www.gnu.org/software/make/). + +* ["`meson.build`"](https://github.com/git/git/blob/master/meson.build) to build using [Meson](https://mesonbuild.com/). * ["Installing from Source"](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git#_installing_from_source) in the Pro Git book @@ -30,16 +35,20 @@ suggest improvements. Thanks! * [Fabien Sanglar's Git Source Code Review](https://fabiensanglard.net/git_code_review/architecture.php) +* [DeepWiki git/git, an AI generated introduction level overview](https://deepwiki.com/git/git) + * [Boost Your Programming Skills by Reading Git's Code](https://www.freecodecamp.org/news/boost-programming-skills-read-git-code/) ## Getting started hacking and contributing * ["My First Contribution"](https://git-scm.com/docs/MyFirstContribution) -* ["My First Object Walk"](https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.txt) +* ["My First Object Walk"](https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.adoc) * [Matheus' tutorial](https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git) +* [Eric Ju's "Contribute-to-Git: A beginner's Guide" wiki](https://gitlab.com/gitlab-org/git/-/wikis/Contribute-to-Git:-A-beginner's-Guide) + * ["Hacking Git"](https://git-scm.com/docs/user-manual#hacking-git) in the Git User's Manual * ["`Documentation/technical`"](https://github.com/git/git/tree/master/Documentation/technical), technical documentation (also viewable at `https://git-scm.com/docs/`) @@ -52,15 +61,17 @@ suggest improvements. Thanks! * ["`SubmittingPatches`"](https://git-scm.com/docs/SubmittingPatches/) -* [Git for Windows' "Good commits"](https://github.com/git-for-windows/git/wiki/Good-commits) +* [Git for Windows' "Good commits"](https://gitforwindows.org/good-commits) ## Process related tools and sites * [GitGitGadget](https://gitgitgadget.github.io/) makes it easy to send patches to the mailing list. -* [lore.kernel.org/git](https://lore.kernel.org/git/) is our prefered mailing list archive. +* [Sending patches by email with git](https://flusp.ime.usp.br/git/sending-patches-by-email-with-git/) is Matheus' git send-email tutorial. -* [public-inbox](https://public-inbox.org/README.html) is the software behing lore.kernel.org. +* [lore.kernel.org/git](https://lore.kernel.org/git/) is our preferred mailing list archive. + +* [public-inbox](https://public-inbox.org/README.html) is the software behind lore.kernel.org. * [lore+lei](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) helps take advantage of lore/public-inbox. @@ -76,16 +87,12 @@ suggest improvements. Thanks! * [Junio's "What's cooking in git.git" emails](https://lore.kernel.org/git/?q=s%3A%22What%27s+cooking+in+git.git%22) list the status of various development topics. -* [Git's release calendar](https://tinyurl.com/gitCal) shows the planned release cycles, the maintainer's planned offline time, the Review Club meetings and possibly other events. +* [Git's release calendar](https://tinyurl.com/gitCal) shows the planned release cycles, the maintainer's planned offline time, and possibly other events. * [Git Rev News](https://git.github.io/rev_news/archive/) newsletter. * [Git Merge conference](https://git-merge.com/). -* [Review Club announces and discussions on the list](https://lore.kernel.org/git/?q=s%3A%22Review+Club%22). - -* [Review Club meeting notes](https://docs.google.com/document/d/14L8BAumGTpsXpjDY8VzZ4rRtpAjuGrFSRqn3stCuS_w) Google doc. - * [Discussions about Contributor(s) Summits on the list](https://lore.kernel.org/git/?q=s%3AContributor*+Summit) ## Branching workflow @@ -96,18 +103,20 @@ suggest improvements. Thanks! * [`gitworkflows`](https://git-scm.com/docs/gitworkflows) manual page -* ["How to maintain Git"](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt) +* ["How to maintain Git"](https://github.com/git/git/blob/master/Documentation/howto/maintain-git.adoc) * ["How the Creators of Git do Branching"](https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb), and the associated [gitworkflow](https://github.com/rocketraman/gitworkflow) repository ## Debugging -* [Git for Windows' Debugging Git](https://github.com/git-for-windows/git/wiki/Debugging-Git) +* [Git for Windows' Debugging Git](https://gitforwindows.org/debugging-git) * [Launching GDB explanations in CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines#L441-L445) * [Philippe Blain's "Debugging Git" Gist](https://gist.github.com/phil-blain/17c67740bd26e66f4851fe0c07230ea4) +* [Debugging test failure using gdb example](https://public-inbox.org/git/CAP8UFD3Bd4Af1XZ00VyuHnQs=MFrdUufKeePO1tyedWoReRjwQ@mail.gmail.com/) + ## Tests * ["`t/README`"](https://github.com/git/git/blob/master/t/README) @@ -122,8 +131,12 @@ suggest improvements. Thanks! * [#git-devel IRC channel archive](https://colabti.org/irclogger/irclogger_logs/git-devel) +* [Git Community Discord Server](https://discord.gg/NKY7fFue) + * [git-mentoring mailing list](https://groups.google.com/forum/#!forum/git-mentoring) +* ["A note from the maintainer"](https://github.com/git/git/blob/todo/MaintNotes) + ## Mentoring programs * [Google Summer of Code](https://summerofcode.withgoogle.com/) diff --git a/Mentoring-Program-Guide.md b/Mentoring-Program-Guide.md index 101dbbb25d..52d2b47960 100644 --- a/Mentoring-Program-Guide.md +++ b/Mentoring-Program-Guide.md @@ -35,7 +35,7 @@ actually starts, (GSoC calls this the "Community Bonding" period,) is a blog. You might want to check which blogging tools previous Outreachy -interns and GSoC students used. Using a Git related tools is of course +interns and GSoC contributors used. Using a Git related tools is of course a good idea. - [Miriam Rubio's Outreachy intership experiences](https://mirucam.gitlab.io/outreachy_blog/) @@ -56,6 +56,43 @@ abilities and dedication. A good example is Matheus' GSoC blog posts: [Matheus Tavares' GSoC posts](https://matheustavares.gitlab.io/tags/gsoc/) +Tip: It's better if you can decide the day for your weekly blog post +as soon as you set up you blog. Then tell your mentors about that day +right away, and try as much as possible to post every week on that +day. This will help establish a routine, that will make things easier +for both you and your mentors. + +Tip: It's also better if you can prepare the content of your weekly +blog post during the week as you are working on your project. This way +it can also serve you as a todo list, a notebook, a list of current +issues, etc. + +## Social media and blog post content + +In general posting about your GSoC on social media (like LinkedIn) is +nice too. You can put links to your blog post in your social media +posts, as they are usually shorter than blog posts. + +You can start blogging as soon as your mentors contact you after you +have been officially selected to participate in the mentoring +program. It's in fact a nice idea to start blogging right after they +have contacted you. + +In all your posts (on your blog or social media), when you mention +your mentors and when they are mentoring you as part of their job, +it's nice to mention the companies they are working for too. Some +mentors could mentor you in their free time, and might not want their +employer mentioned though. So if you are not sure that it's part of +their job, just ask them before posting. In case of Outreachy if some +company sponsors your internship, it's a very good idea to mention +them too. + +The more these companies get good mentions in the media about your +GSoC, and the more good work you deliver during it, the more likely +they are to allow their employees to mentor others, or even to sponsor +mentoring programs (like Outreachy internships for example), or maybe +to hire or help you in the future. + ## Regular updates Mentors should be regularly updated about your work, so they can know @@ -99,15 +136,15 @@ mailing list, it is important that you cover all the following topics: 4. what things you think should be easier 5. what you are planning to work on and how -The reason we ask for 2), 3) and 4) is that often interns or students -don't know about things, like existing documentation, historical -discussions, debugging scripts, features, tools or techniques, that -could help them understand what's going on, or work in a more -efficient way. If a mentor doesn't know that the intern or student is -blocked or slowed by something or has a hard time moving forward, it's -difficult for the mentor to help. So it's important for interns or -students to reflect on the issues, blocks, inefficiencies, complex -things that they are facing. +The reason we ask for 2), 3) and 4) is that often interns or +contributors don't know about things, like existing documentation, +historical discussions, debugging scripts, features, tools or +techniques, that could help them understand what's going on, or work +in a more efficient way. If a mentor doesn't know that the intern or +contributor is blocked or slowed by something or has a hard time +moving forward, it's difficult for the mentor to help. So it's +important for interns or contributors to reflect on the issues, +blocks, inefficiencies, complex things that they are facing. Notifying the mailing list or your mentors about a blog post, should not prevent you from emailing or contacting the mailing list or your @@ -167,9 +204,9 @@ list that people debug together or discuss together something over email in a very real-time way (at least similar as instant messaging chat). -Such chats can sometimes help a student or intern (or even long timers -on the project) move very fast in a short amount of time. So consider -taking advantage of that. +Such chats can sometimes help a contributor or intern (or even long +timers on the project) move very fast in a short amount of time. So +consider taking advantage of that. It's also easier for mentors to help (or understand how they could help) when discussing informally using a real time or near real time @@ -342,13 +379,271 @@ A few things that you might want to do are: - Don't forget using [RFC] or [WIP], if it's relevant. +# Resources, rules, documentation and links + +We encourage you to get as much help as you can from your mentors and +the Git community according to the suggestions in the "Communication" +section above. + +Nevertheless you are also welcome to get help in many different ways +that might not be mentioned above. Such help can come from the +community, its people, tools, documentation or websites, as well as +other people, tools or websites. You have to do most of the actual +work and follow some rules though. + +The following sections list some of these resources (people, tools, +documentation, websites, etc.), sometimes along with suggestions about +when they might be useful. + +Some of these resources are also important as they can help you learn +about the rules. + +## People + +When communicating with other people, we encourage you to keep your +mentors (or perhaps the whole community) in the loop though, if +possible. + + - Individual contributors + + When someone contributed to something very relevant to your work, + you might want to privately ask for help from them as they might + know more and might be able to help you better than your mentors + in some areas of your work. + + - Org Admins (people responsible for Git being involved in the + mentoring program) + + They could be useful if, for example, you, along perhaps with your + mentors, want to extend or change the duration of your mentoring + program (if it is allowed by the mentoring program). + + - Mentoring Program organizers + + If you have issues related to the mentoring program, you can + likely reach out to them. + + - Git PLC (Project Leadership Committee) members + + They are responsible for communicating with the + [Software Freedom Conservancy](https://sfconservancy.org/), + which is Git's parent nonprofit organization. They are also + responsible for enforcing Git's Code of Conduct, especially on the + Git mailing list. + +## Important community documentation and rules + +Please read, and try to keep in mind, the important documentation +below: + + - [Git's Code of Conduct](https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md) + + This can be useful if others' behavior annoys you or if your + behavior might annoy other people. + + - [Git's SubmittingPatches doc](https://github.com/git/git/blob/master/Documentation/SubmittingPatches) + + This documentation contains the + [Developer's Certificate of Origin, or DCO for short](https://git-scm.com/docs/SubmittingPatches#sign-off), + which you have to know about when contributing to Git. + + - [Git's license](https://github.com/git/git/blob/master/COPYING) + + It makes sure that Git, and the contribution you make to it, are + free and open source software. You also have to know about it to + fully make sense of the DCO above. + +## Other community websites + +Please take a quick tour of those websites, if you haven't already, to +know about all the resources that they make available to you. + +Also note that you are very much encouraged to contribute to improving +these sites during your mentoring program. It's very much appreciated, +as it shows that you care about those who will come after you, even if +it's not part of your main work. + + - [Git Developer Pages](https://git.github.io/) + + This is the home of this very documentation and Git's mentoring + program related documentation. It also contains the + [Hacking-Git page](https://git.github.io/Hacking-Git/) + which has a number of helpful links. + + This website is maintained through + [its GitHub repo](https://github.com/git/git.github.io). + + - [Git Documentation website](https://git-scm.com/) + + This is the main Git website, with Git reference documentation + automatically generated from the + [Documentation folder](https://github.com/git/git/tree/master/Documentation) + of the Git repo, as well as a free book, and general information + about Git, including community information. + + This website is maintained through + [its GitHub repo](https://github.com/git/git-scm.com). + +## Other links + + - [Outreachy website](https://www.outreachy.org) + + - [GSoC website](https://summerofcode.withgoogle.com) + +# Roadblocks and Benefits + +Successfully participating in a mentoring program with Git can boost +your career in a number of different ways. Also even if it requires +working regularly and being open to mentoring, it's not very +difficult. We estimate that around 80% or more of the people we accept +succeed. + +## Roadblocks + +It's possible that you will encounter difficulties in moving forward +in your project. We try to list a few common ones here, along with +some advice to help overcome them. + +In general it's a good idea to discuss such issues with your mentor(s) +as early as possible. This way you might get some help and be able to +try different solutions before it's too late. One possible way to +alleviate some issues could be to extend the mentoring period if the +mentoring program allows it. + +### Dedicated time + +The main thing that could prevent you from succeeding is not having or +dedicating enough time to work on your project. Some people we +mentored had university classes, or found a full time job, or took +some long vacation, or spent a lot of time with their family, which +prevented them from dedicating enough time to their project. This +resulted in us having to fail them, which is sad for everyone. + +If you are planning to spend a significant amount of time doing other +things than working on your project during the mentoring program, it +might be better to not participate in it in the first place. You will +save yourself and your mentor(s) a significant amount of frustration, +and you will likely allow someone else to be successfully mentored and +gain a lot from that experience. + +Other roadblocks can more easily be overcome than not dedicating +enough time. Even if you can work a lot, you will need a bit of free +time during the mentoring program, so you may make things very +difficult for yourself if you are planning to work on both your +project and other things at the same time. Be considerate towards +yourself and do not put yourself in such a bad situation in the first +place. + +### Asking for help + +Another thing that could slow you is if it's difficult for you to +share with your mentor(s) about the technical hurdles you face. It +could be that you have trouble debugging or understanding how things +work or are supposed to work, and are afraid of asking for help. + +When we review your work, we provide technical suggestions, but when +you are starting it or in the middle of it, you are usually alone and +it can be difficult for you to ask your mentor(s) to take a look at +it. Please consider that the more transparent you are about your work, +and the more precise and specific you are in your questions, the +easier it is for us to help you, and for you to move forward. + +We only request that you spend around 10 minutes trying to find a +solution by yourself before you ask us about something. When you have +tried to find a solution, it's also a good idea to tell us what you +have tried or how you searched, as we can often help you be more +efficient in this too. + +### Personal issues + +Yet another roadblock that could sometimes prevent you from succeeding +is personal issues of different kinds. They are sometimes related to +your family or your partner. They are sometimes related to the other +potential roadblocks above. + +In general it's a good idea to talk about them early with your mentor, +as we just cannot properly handle difficult personal situations we are +not aware of. And regular communication, even using video chat, might +not be enough to suspect that your personal situation might be +difficult, if you are not explicit about it. + +## Benefits + +There are a lot of benefits in participating in mentoring programs +with the Git project, not just the fact that the programs pay the +participants a significant amount of money. + +And it's not limited to the first time you participate. The more you +participate, the more benefits you will reap. Participating as a +mentor or a co-mentor after you have been mentored, or becoming a +regular contributor, will also reflect very well on you and increase a +number of benefits you get. It's also relatively easy, as you have +already overcome the most difficult parts. + +### Career boost + +A number of former participants in a mentoring program with us have +reported that it significantly boost their career, as they much more +easily got job interviews, and then job offers with more well known +companies. + +### Improved technical skills + +Former participants also reported that they felt their software +engineering skills improved significantly. + +This is not just that they became more proficient with Git and source +code management in general. It's a also at least about improved +programming, testing, reviewing and collaborating skills. + +### Improved self confidence + +We believe that being able to contribute significantly to a well known +project like Git, also helps improve participants' self-confidence. +They are likely to be less afraid to participate in and contribute to +more complex software projects. + +### Improved Internet credibility + +We strongly encourage the participants we mentor to create a blog +about their work and regularly post on their blog, as we believe that +it helps them in many ways. We encourage them to post on social media +too. + +We also mention participants in our Git Rev News newsletter both after +they have been selected into a mentoring program, and after they +successfully finished it. + +Sometimes they get mentioned, or interviewed, in the blog posts of +some well known Git related companies too, like for example: + + - [this GitLab blog post about Outreachy](https://about.gitlab.com/blog/2021/04/15/outreachy-sponsorship-winter-2020/), or + - [this GitHub blog post about the Git 2.43 release](https://github.blog/2023-11-20-highlights-from-git-2-43/), + where Kousik's GSoC 2023 work is mentioned. + +### Meeting us at some conferences + +We try to help successful participants come to the +[Git Merge conference](https://git-merge.com/) +and meet the community, often including their mentor(s), there. For +that the Git project offers to reimburse the participants' travel +expenses. + +This is sometimes not possible due to visa issues, or the fact that +the Git Merge unfortunately doesn't happen every year, though. + # Conclusion -Hope you got an idea about how things usually go during the mentoring -period of a mentoring program such as GSoC or Outreachy. As a reminder, -don't be surprised if your mentors ask for things that are a bit different -than what is described here. Typically your mentors will expect that you -become more autonomous over time and will adjust things depending on -how autonomous you already are. +We hope you got an idea about how you will likely work with your +mentor(s) and how things usually go during the mentoring period of a +program such as GSoC or Outreachy. We hope you are also aware of the +people, communication means and resources available to help you, as +well as the rules you have to follow, the roadblocks you might +encounter and the benefits you may reap. + +As a reminder, don't be surprised if your mentors ask for things that +are a bit different than what is described here. Typically your +mentors will expect that you become more autonomous over time and will +adjust things depending on how autonomous you already are. Wishing you luck during your mentoring period! diff --git a/Outreachy-21-Microprojects.md b/Outreachy-21-Microprojects.md index 2c9762fdc7..cffa96590f 100644 --- a/Outreachy-21-Microprojects.md +++ b/Outreachy-21-Microprojects.md @@ -89,6 +89,6 @@ untracked file in the submodule directory. This is inconsistent with what `git describe --dirty` says when run in the submodule directory in that state. -Fix `git diff` to use the same definition of dirtyness for such a +Fix `git diff` to use the same definition of dirtiness for such a submodule directory (or the other way around). [[cf](https://lore.kernel.org/git/xmqqo8m1k542.fsf@gitster.c.googlers.com)] diff --git a/Outreachy-Participants.md b/Outreachy-Participants.md new file mode 100644 index 0000000000..53c7fed07e --- /dev/null +++ b/Outreachy-Participants.md @@ -0,0 +1,60 @@ +--- +layout: default +title: Outreachy participants +--- + +This document collects the list of contributors who've contributed +to Git via Outreachy. + +### Winter 2024-2025 + +1. Seyi Kuforiji [ [blog](https://seyi-kuforiji-902b48.gitlab.io/) ] +2. Usman Akinyemi [ [blog](https://uniqueusman.hashnode.dev/tag/outreachy) ] + +#### References + +- [Rev News - Dec 2024](https://git.github.io/rev_news/2024/12/31/edition-118/) + +### Winter 2023-2024 + +1. Achu Luma [ [blog](https://lumap.gitlab.io/posts/) ] + +#### References + +- [Rev News - Dec 2023](https://git.github.io/rev_news/2023/11/30/edition-105/) + +### Winter 2020-2021 + +1. Sangeeta [ [blog](https://sangu09.github.io) ] +2. Joey Salazar [ [blog](https://jsal.home.blog/) ] +3. Charvi Mendiratta [ [blog](https://charvi-077.github.io/blog/) ] + +#### References + +- [Rev News - Dec 2020](https://git.github.io/rev_news/2020/12/26/edition-70/) + +### Winter 2019-2020 + +1. Heba W. [ [blog](https://medium.com/@heba.waly) ] +2. Miriam Rubio [ [blog](https://mirucam.gitlab.io/outreachy_blog/) ] + +#### References + +- [Rev News - Dec 2019](https://git.github.io/rev_news/2019/12/25/edition-58/) + +### Winter 2018-2019 + +1. Slavica Đukić [ [blog](https://slavicadj.github.io/blog/) ] +2. Tanushree Tumane [ [blog](https://tanu1596.blogspot.com/) ] + +#### References + +- [Rev News - Nov 2018](https://git.github.io/rev_news/2018/11/21/edition-45/) + +### Winter 2017-2018 + +1. Olga Telezhnaia [ [blog](https://medium.com/@olyatelezhnaya) ] + +#### References + +- [Rev News - Nov 2017](https://git.github.io/rev_news/2017/11/22/edition-33/) diff --git a/README.md b/README.md index 1ea95e5396..99d8801805 100644 --- a/README.md +++ b/README.md @@ -11,6 +11,25 @@ - These pages are intended to be edited collaboratively (i.e., it is an alternative to us having a wiki, but one that is edited entirely via Git pushes). + You could also send your changes as patches by email to Christian Couder < > / Kaartic Sivaraam < > (and feel free to cc git@vger.kernel.org if appropriate). + + +### Development + +If you wish to spin up the site locally, you could follow the steps below. + +* Make sure you've got ruby2 with dev-packages installed +* `sudo gem install bundler` +* Clone this repo +* `sudo apt-get install zlib1g-dev` # [ + [ref](http://www.nokogiri.org/tutorials/installing_nokogiri.html#ubuntu___debian) + ] +* `bundle install` +* `bundle exec jekyll serve` +* browse the site on http://localhost:4000 + +Based on https://help.github.com/articles/using-jekyll-with-pages/ +
diff --git a/SoC-2014-Microprojects.md b/SoC-2014-Microprojects.md index dceeccf260..f735a8a307 100644 --- a/SoC-2014-Microprojects.md +++ b/SoC-2014-Microprojects.md @@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 8d558eca09..2248169e81 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -77,7 +77,7 @@ look for the commit which fixed a bug. It is already possible using "git bisect", but the user has to type "good" to mean "the bug is there" and "bad" to mean "the bug is fixed", which isn't convenient. -It would be nice to allow the user to explicitely say "git bisect +It would be nice to allow the user to explicitly say "git bisect fixed" and "git bisect unfixed" instead. It is actually much harder than defining "fixed"/"unfixed" as aliases for "bad"/"good". diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index b8df3a6ede..de0a0a7293 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2016-Ideas.md b/SoC-2016-Ideas.md index 9d66a0c6d2..c5044c32c6 100644 --- a/SoC-2016-Ideas.md +++ b/SoC-2016-Ideas.md @@ -267,7 +267,7 @@ compressed data from one packfile to another. This would involve looking at the code in git to copy over optimisations as well as figuring out what parts of libgit2 should be -changed to accomodate these new capabilities. +changed to accommodate these new capabilities. - Language: C - Difficulty: medium diff --git a/SoC-2016-Microprojects.md b/SoC-2016-Microprojects.md index 3d3bebda50..54c5184b1b 100644 --- a/SoC-2016-Microprojects.md +++ b/SoC-2016-Microprojects.md @@ -40,7 +40,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the @@ -272,7 +272,7 @@ When you find something you are interested to work on, please ask first on the mailing list if it's worth doing and if it's appropriate for a microproject before starting to work on what you find. Even if it looks straitforward, there could be hidden reasons why it is too -difficult or just innappropriate. +difficult or just inappropriate. ### Searching the code base itself diff --git a/SoC-2017-Microprojects.md b/SoC-2017-Microprojects.md index a0b349c9f5..ef4a09b3e0 100644 --- a/SoC-2017-Microprojects.md +++ b/SoC-2017-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the @@ -262,7 +262,7 @@ When you find something you are interested to work on, please ask first on the mailing list if it's worth doing and if it's appropriate for a microproject before starting to work on what you find. Even if it looks straitforward, there could be hidden reasons why it is too -difficult or just innappropriate. +difficult or just inappropriate. ### Searching the code base itself diff --git a/SoC-2018-Microprojects.md b/SoC-2018-Microprojects.md index 7b4adf734b..8a33938ff8 100644 --- a/SoC-2018-Microprojects.md +++ b/SoC-2018-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2019-Ideas.md b/SoC-2019-Ideas.md index 94315b9c3e..da3b6c8f36 100644 --- a/SoC-2019-Ideas.md +++ b/SoC-2019-Ideas.md @@ -120,7 +120,7 @@ projects versus projects that implement new features though. Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in @@ -137,7 +137,7 @@ See discussion in: - Possible mentors: Christian Couder, Thomas Gummerer A number of Git commands, like `git log`, can show commit information -in a configurable way using ["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.txt). +in a configurable way using ["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.adoc). Such formats though don't yet support some features that users would like, for example to display a log like the following: diff --git a/SoC-2019-Microprojects.md b/SoC-2019-Microprojects.md index 80ef93c4d2..9bec90f907 100644 --- a/SoC-2019-Microprojects.md +++ b/SoC-2019-Microprojects.md @@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed, and after several iterations an improved version of the patch was accepted into our codebase. As a GSoC student, you will be playing the role of the developer and engaging in a similar discussion. Get -familar with the flow, need for clarity on both sides (i.e. you need +familiar with the flow, need for clarity on both sides (i.e. you need to clearly defend your design, and need to ask clarifications when questions/suggestions you are offered are not clear enough), the pace at which the discussion takes place, and the general tone of the diff --git a/SoC-2020-Ideas.md b/SoC-2020-Ideas.md index f2e94aba4e..ce6d43cd62 100644 --- a/SoC-2020-Ideas.md +++ b/SoC-2020-Ideas.md @@ -27,7 +27,7 @@ page though. Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in @@ -45,7 +45,7 @@ See discussion in: A number of Git commands, like `git log`, can show commit information in a configurable way using -["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.txt). +["pretty" formats](https://github.com/git/git/blob/master/Documentation/pretty-formats.adoc). Such formats though don't yet support some features that users would like, for example to display a log like the following: diff --git a/SoC-2021-Ideas.md b/SoC-2021-Ideas.md index 1d1fc3f821..9a69ccb007 100644 --- a/SoC-2021-Ideas.md +++ b/SoC-2021-Ideas.md @@ -32,7 +32,7 @@ possible the same code and syntax as the ref-filter formats. Git used to have an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC -students and Outreachy interns unified some of the formating logic +students and Outreachy interns unified some of the formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. diff --git a/SoC-2022-Ideas.md b/SoC-2022-Ideas.md index 8e3bc62e96..90a0ab1cb6 100644 --- a/SoC-2022-Ideas.md +++ b/SoC-2022-Ideas.md @@ -83,7 +83,7 @@ logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC students and Outreachy interns unified some of the -formating logic into +formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in diff --git a/SoC-2022-Microprojects.md b/SoC-2022-Microprojects.md index 225fb1afaf..6def7c11d8 100644 --- a/SoC-2022-Microprojects.md +++ b/SoC-2022-Microprojects.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2022 Applicant Microprojects +navbar: false --- ## Introduction @@ -46,17 +47,65 @@ functions. 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. -### Avoid pipes in git related commands in test scripts +### Avoid suppressing `git`'s exit code in test scripts + +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 `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). See the commit [c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) for example, and then do the same thing in one other test script. -The git command should be on the left side of the pipe. - 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. +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + ### Use unsigned integral type for collection of bits. Pick one field of a structure that (1) is of signed integral type and (2) is diff --git a/SoC-2023-Ideas.md b/SoC-2023-Ideas.md index 89b4ec2a87..582cfcd75c 100644 --- a/SoC-2023-Ideas.md +++ b/SoC-2023-Ideas.md @@ -1,6 +1,7 @@ --- layout: default title: SoC 2023 Ideas +navbar: false --- This is the idea page for Summer of Code 2023 for Git. @@ -76,7 +77,7 @@ logic. For example, Git had at least 4 different implementations to format command output for different commands. Our previous GSoC students and Outreachy interns unified some of the -formating logic into +formatting logic into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and got rid of similar logic in some command specific files. Current task is to continue this work and reuse ref-filter formatting logic in diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md new file mode 100644 index 0000000000..041eba592c --- /dev/null +++ b/SoC-2024-Ideas.md @@ -0,0 +1,207 @@ +--- +layout: default +title: SoC 2024 Ideas +navbar: false +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2024 for Git. + +*Please completely read the [general application information](https://git.github.io/General-Application-Information) +page before reading the idea list below.* + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive proposals +for other ideas related to Git. Make sure you have read the "Note +about refactoring projects versus projects that implement new +features" in the [general application information](https://git.github.io/General-Application-Information) +page though. + +### Note about limit of project selection + +Kindly note that considering the bandwidth of available mentors, the +Git project would only mentor up to 3 contributors this year. + +This is not a hard and fast rule. It may change if more community members are +willing to mentor in the coming days. For instance, this may happen when +a new project is proposed and some community member volunteers to mentor +the same. + +### Move existing tests to a unit testing framework + +Git has a lot of test cases that need to be migrated to use a new unit +testing framework. This typically involves moving code from both: + + - a "t/helper/test-*.c" test helper in C, and + - a "t/*.sh" test script in shell that invokes the test helper + +over to a single "t/unit-tests/t-*.c" in C using the unit testing +framework. + +Our Outreachy intern ported some of the unit tests. + +**Note**: Owing to additional care needed to convert +reftable unit tests in `t0032-reftable-unittest.sh`, +it is covered as a separate project below. +So, this project solely focuses on unit tests _other than_ +the reftable ones. + +- See: + + - this discussion + - + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Christian Couder < > +* Kaartic Sivaraam < > + +### 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 + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Low + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### 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: + + - + - + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > + +### 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: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > +* Christian Couder < > + +### Implement support for reftables in "dumb" HTTP transport + +Fetching Git repositories uses one of two major protocols: + + - The "dumb" protocol works without requiring any kind of + interactive negotiation like a CGI module. It can thus + be served by a static web server. + + - The "smart" protocol works by having the client and + server exchange multiple messages with each other. It is + more efficient, but requires support for Git in the + server. + +While almost all servers nowadays use the "smart" protocol, +there are still some that use the "dumb" protocol. + +The "dumb" protocol cannot serve repositories which use the +"reftable" backend though. While there exists a "info/refs" +file that is supposed to be backend-agnostic, this file does +not contain information about the default branch. Instead, +clients are expected to download the "HEAD" file and derive +the default branch like that. This file is a mere stub in +the "reftable" backend though, which breaks this protocol. + +The goal of this project is to implement "reftable" support +for "dumb" fetches. + +See: + + - + +Expected Project Size: 175 hours or 350 hours + +Difficulty: Medium + +Languages: C, shell(bash) + +Possible mentors: +* Patrick Steinhardt < > +* Karthik Nayak < > diff --git a/SoC-2024-Microprojects.md b/SoC-2024-Microprojects.md new file mode 100644 index 0000000000..c832f49f30 --- /dev/null +++ b/SoC-2024-Microprojects.md @@ -0,0 +1,144 @@ +--- +layout: default +title: SoC 2024 Applicant Microprojects +navbar: false +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Add more builtin patterns for userdiff + +"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. + +This project requires a very good knowledge of regular expressions. + +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. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +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. + +### Use `test_path_is_*` functions in test scripts + +Find one test script that verifies the presence/absence of +files/directories with 'test -(e|f|d|...)' and replace them with the +appropriate `test_path_is_file`, `test_path_is_dir`, etc. helper +functions. Note that this conversion does not directly apply to control +flow constructs like `if test -e ./path; then ...; fi` because the +replacements are intended to assert the condition instead of merely +testing for it. Check [this link](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) +for an elaborate clarification on identifying `test -e` +instances that should / should not be replaced. + +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. + +### Avoid suppressing `git`'s exit code in test scripts + +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 `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +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. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +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. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +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. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +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. + +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. diff --git a/SoC-2025-Ideas.md b/SoC-2025-Ideas.md new file mode 100644 index 0000000000..fac121ab43 --- /dev/null +++ b/SoC-2025-Ideas.md @@ -0,0 +1,172 @@ +--- +layout: default +title: SoC 2025 Ideas +--- + +![git logo >](https://git-scm.com/images/logos/downloads/Git-Logo-2Color.svg) + +This is the idea page for Summer of Code 2025 for Git. + +*Please completely read the [general application information](https://git.github.io/General-Application-Information) +page before reading the idea list below.* + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive proposals +for other ideas related to Git. Make sure you have read the "Note +about refactoring projects versus projects that implement new +features" in the [general application information](https://git.github.io/General-Application-Information) +page though. + +### Note about limit of project selection + +Kindly note that considering the bandwidth of available mentors, the +Git project would only mentor up to 3 contributors this year. + +This is not a hard and fast rule. It may change if more community members are +willing to mentor in the coming days. For instance, this may happen when +a new project is proposed and some community member volunteers to mentor +the same. + + +### Consolidate ref-related functionality into git-refs + +This project aims to streamline Git's reference management into the existing +`git-refs` command by consolidating functionality currently spread +across multiple commands. The new command will provide subcommands for listing, +getting, checking existence, writing, and optimizing references, replacing the +functionality currently handled by git-update-ref(1), git-for-each-ref(1), +git-show-ref(1), and git-pack-refs(1). + +The consolidation work should ensure backward compatibility with existing +commands. The work involves C programming in Git's codebase, creating +comprehensive tests, and updating documentation. + +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. + +Getting started: Build Git from source, study the existing ref-related commands, and submit a micro-patch to demonstrate familiarity with the codebase. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Jialuo She < > +* Christian Couder < > +* Ghanshyam Thakkar < > + + +### Refactoring in order to reduce Git's global state + +This project focuses on modernizing Git's environment handling by refactoring +the `environment.c` code to reduce global state. The goal is to move environment +variables and configuration from global scope into more appropriate local +contexts, primarily into the `struct repository` / `struct repository_settings` +structure. This architectural improvement will make the codebase more +maintainable and potentially enable better multi-repository handling in the +future. The project involves careful refactoring of Git's core environment +handling code, requiring strong C programming skills and attention to detail. + +The student will identify global variables that can be moved to local scope, +implement the necessary structural changes, and ensure all affected code paths +continue to work correctly. This includes updating tests, fixing any +regressions, and documenting the architectural changes. + +_Expected Project Size_: 90 or 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Karthik Nayak < > +* Jialuo She < > +* Christian Couder < > +* Ghanshyam Thakkar < > + + +### Machine-Readable Repository Information Query Tool + +This project aims to create a new Git command dedicated to querying repository +metadata and configuration in a structured, machine-readable format. Currently, +much of this functionality exists within git-rev-parse(1), which has evolved +beyond its original purpose. The new command will provide a cleaner, more +focused interface for programmatically accessing repository information using +JSON output. + +The student will design and implement this new command, focusing on identifying +what repository information should be exposed, designing a consistent JSON +schema, and implementing the necessary interfaces to Git's internal APIs. Key +challenges include determining which subset of information from git-rev-parse to +expose via this new command, ensuring backward compatibility, and creating a +clean, well-documented command interface that's useful for scripts and tools. + +While this is an exploratory project that hasn't been extensively discussed in +the Git community, it addresses a real need for better programmatic access to +repository information. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: + +* Patrick Steinhardt < > +* Karthik Nayak < > +* Ghanshyam Thakkar < > + + +### Implement support for reftables in "dumb" HTTP transport + +Fetching Git repositories uses one of two major protocols: + + - The "dumb" protocol works without requiring any kind of + interactive negotiation like a CGI module. It can thus + be served by a static web server. + + - The "smart" protocol works by having the client and + server exchange multiple messages with each other. It is + more efficient, but requires support for Git in the + server. + +While almost all servers nowadays use the "smart" protocol, +there are still some that use the "dumb" protocol. + +The "dumb" protocol cannot serve repositories which use the +"reftable" backend though. While there exists a "info/refs" +file that is supposed to be backend-agnostic, this file does +not contain information about the default branch. Instead, +clients are expected to download the "HEAD" file and derive +the default branch like that. This file is a mere stub in +the "reftable" backend though, which breaks this protocol. + +The goal of this project is to implement "reftable" support +for "dumb" fetches. + +See: + + - + +**Note**: While both ideas are valuable, we prioritize the 'Consolidate ref-related +functionality into git-refs' proposal over support for reftables in "dumb" HTTP transport. If we receive applications for both +projects, preference will be given to applications focusing on the git-refs +consolidation work. + +_Expected Project Size_: 175 hours or 350 hours + +_Difficulty_: Medium + +_Languages_: C, shell(bash) + +_Possible mentors_: +* Patrick Steinhardt < > +* Karthik Nayak < > diff --git a/SoC-2025-Microprojects.md b/SoC-2025-Microprojects.md new file mode 100644 index 0000000000..5a5db49eae --- /dev/null +++ b/SoC-2025-Microprojects.md @@ -0,0 +1,181 @@ +--- +layout: default +title: SoC 2025 Applicant Microprojects +--- + +## Introduction + +First make sure you read and understand +[our general guidelines and suggestions for microprojects](https://git.github.io/General-Microproject-Information). + +There are some suggestions on how you can find some microprojects on your own in the document. + +## Ideas for microprojects + +### Modernize Test Path Checking in Git's Test Suite + +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 `test -f` +with Git's dedicated test helpers like `test_path_is_file`. + +#### Steps to Complete +1. Find a test script using old-style path checks: + ```sh + git grep "test -[efd]" t/ + ``` + +2. Look for patterns like: + ```sh + test -f path/to/file # old way + test_path_is_file path/to/file # new way + + test -d some/directory # old way + test_path_is_dir some/directory # new way + ``` + +3. Important: Only replace checks that are actually testing for conditions, not + those used in flow control. For example: + ```sh + # DON'T change this - it's flow control + if test -e "file.txt"; then + do_something + fi + + # DO change this - it's a test assertion + test -e "file.txt" || error "file.txt should exist" + ``` + +#### Notes +- Start small: Pick a test file with just a few instances to convert +- Run the test suite after your changes to ensure nothing breaks +- Follow Git's commit message style +- Include which command you used to find the instances in your commit message + +#### Need Help? +- Reference [this discussion](https://public-inbox.org/git/CAPig+cRfO8t1tdCL6MB4b9XopF3HkZ==hU83AFZ38b-2zsXDjQ@mail.gmail.com/) + for detailed examples. +- If you can't find any instances to fix, let us know what search command you + used + + +### Add more builtin patterns for userdiff + +"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. + +This project requires a very good knowledge of regular expressions. + +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. + +### Replace a run_command*() call by direct calls to C functions + +See for example what Junio did in +[ffcb4e94d3](https://github.com/git/git/commit/ffcb4e94d3) (bisect: do +not run show-branch just to show the current commit, 2021-07-27). + +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. + +### Avoid suppressing `git`'s exit code in test scripts + +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 `t` directory +[here][git-t]. + +While it is perfectly OK to use [pipes][wikipedia-pipes] when writing +integration tests, we must be careful to avoid writing a pipeline that +suppresses the exit code of a Git process, like so: + +``` +git | +``` + +...since the exit code of `git ` would be suppressed by the +pipe. If `git ` crashed, we would not catch it in the above +example when running the integration suite. + +Other examples to avoid include: + +``` +# bad: + $(git ) + +# also bad: + <) +EOF +``` + +...since the exit code of `git ` is hidden behind the +subshell in both instances. + +On the other hand, both of the following examples are OK, since neither +hides the exit code of running `git `: + +``` +# good: +var=$(git ) + +# also good: + | | git +``` + +(provided that neither `` or `` are +`git`). + +See the commit +[c6f44e1da5](https://github.com/git/git/commit/c6f44e1da5e88e34) +for example, and then do the same thing in one other test script. + +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. + +[git-t]: https://github.com/git/git/tree/master/t +[wikipedia-pipes]: https://en.wikipedia.org/wiki/Pipeline_(Unix) + +### Use unsigned integral type for collection of bits. + +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. [[thread](https://public-inbox.org/git/xmqqsiebrlez.fsf@gitster.dls.corp.google.com)] + +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. + +### Modernize a test script + +A number of our test scripts have been written a long time ago in a +style that is now outdated. + +In the following email it is explained in details how to modernize and +clean up the t7001 test script: + + + +t7001 is not the only test script where similar changes could be made +though. + +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. + +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. + +#### Notes +- only work on `t/t????-*.sh` scripts. +- pick just one script (so as to avoid exhausting the pool for other candidates). +- When converting `test -[def]` to use `test_path_exists()` and cousins + only convert instances which semantically are assertions (i.e. used as part + of a &&-chain). diff --git a/_config.yml b/_config.yml index 7633f45e70..f3e563f9aa 100644 --- a/_config.yml +++ b/_config.yml @@ -1,2 +1,4 @@ name: Git Developer Pages permalink: /rev_news/:year/:month/:day/:title/ +plugins: + - jekyll-redirect-from \ No newline at end of file diff --git a/_includes/README.md b/_includes/README.md index ea8fb22500..d70f2c116c 100644 --- a/_includes/README.md +++ b/_includes/README.md @@ -1,41 +1,22 @@ -# About Git Developer Pages - -This is a website to help Git Developers. - -It is NOT a place to discuss Git issues. Please see -[git-scm.org's community page](https://git-scm.com/community) -for information about bug reporting or interacting with the -community. - -The pages are maintained by editing files in the -[git/git.github.io](https://github.com/git/git.github.io) repository on -GitHub. It is then published on the -[https://git.github.io](https://git.github.io) GitHub page. - -It is meant to be edited collaboratively like a wiki, except that -instead of a web form, you get to use a text editor and Git. What could -be better? - -These pages also host the [Git Rev News](https://git.github.io/rev_news/), -see the [About Git Rev News](https://git.github.io/rev_news/rev_news/) page. - -If you want push access, contact Christian Couder -< > or Taylor Blau < > and -provide your GitHub username. You may also send patches by mail (and -feel free to cc git@vger.kernel.org if appropriate). - - -# Development - -* Make sure you've got ruby2 with dev-packages installed -* `sudo gem install bundler` -* Clone this repo -* `sudo apt-get install zlib1g-dev` # ref [1] -* `bundle install` -* `bundle exec jekyll serve` -* browse the site on http://localhost:4000 - -Based on https://help.github.com/articles/using-jekyll-with-pages/ - -[1] http://www.nokogiri.org/tutorials/installing_nokogiri.html#ubuntu___debian - +This is a website for information on Git development. If you stumbled into this +by mistake, you may want: + - Information on running Git and links to download the latest version from + [HERE](https://git-scm.com/) + - Wiki that has historically contained developer information from + [HERE](https://git.wiki.kernel.org/index.php/Main_Page) + +These pages are intended to collect information useful to Git developers. This +is also the web home of: + - the [Hacking Git](https://git.github.io/Hacking-Git/) page, + - the [Git Rev News newsletter](https://git.github.io/rev_news/), + - the [involvement of the Git project in mentoring + programs](https://git.github.io/General-Application-Information/) like + [Outreachy](https://www.outreachy.org/) and the [GSoC (Google Summer of + Code)](https://summerofcode.withgoogle.com/) + +These pages are intended to be edited collaboratively (i.e., it is an +alternative to us having a wiki, but one that is edited entirely via Git pushes. +The [repository](https://github.com/git/git.github.io) could be found on GitHub. +You could also send your changes as patches by email to Christian Couder < + > / Kaartic Sivaraam < > +(and feel free to cc git@vger.kernel.org if appropriate). diff --git a/_includes/navbar.html b/_includes/navbar.html index 6d52b36c9f..d4dfe25bda 100644 --- a/_includes/navbar.html +++ b/_includes/navbar.html @@ -1,7 +1,6 @@