Skip to content

Latest commit

 

History

History
306 lines (249 loc) · 16.4 KB

2022-11-30-edition-93.markdown

File metadata and controls

306 lines (249 loc) · 16.4 KB
title layout date author categories navbar
Git Rev News Edition 93 (November 30th, 2022)
default
2022-11-30 12:06:51 +0100
chriscool
news
false

Git Rev News: Edition 93 (November 30th, 2022)

Welcome to the 93rd edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.

This edition covers what happened during the month of October 2022.

Discussions

Reviews

  • [PATCH] archive: add --recurse-submodules to git-archive command

    Heather Lapointe sent a patch to the mailing list that enabled git archive to also include submodule contents in the archives it produces.

    She said she was inspired by a GitHub issue more than 160 upvotes and thought the implementation wouldn't be too difficult as most of the plumbing was already in place.

    One of the trickier parts was changing the read_tree() function to support other repos than the current one by not using the the_repository global variable.

    Heather soon sent a version 2 patch series. This patch series contained only 2 patches. The first one was identical to the one previously sent, while the second one fixed a submodule traversal bug in read_tree() introduced by the first patch.

    René Scharfe replied to Heather, noticing that the cover letter of the patch series had a TODO list with a number of items, most of which seemingly already addressed. As the stats in the cover letter showed 16 files changed, 269 insertions, and 96 deletions, he said it was a bit much for a few patches, and suggested splitting them.

    Heather replied to René that the TODO list came from GitGitGadget. And René found that this tool was using an HTML-to-text converter that doesn't handle checkboxes nicely by default. René and Heather then discussed how to split the patches, and a bit how the first patch was implemented.

    Heather then sent a version 3 of her patch series that split her previous patch series into 8 patches.

    Junio Hamano, the Git maintainer, along with Glen Choo, Jonathan Tan, Phillip Wood and Ævar Arnfjörð Bjarmason all commented on some of the patches in this series and suggested small improvements.

    The Review Club selected this patch series to be reviewed by participants on Wednesday October 26, and participants generally agreed that "this is a really well-structured and easy-to-follow series :)" and that "as far as new contributions go, this is really good".

    Unfortunately it looks like Heather has been swamped with her own work and didn't have time to send a new version yet. Hopefully though we will get this very requested feature soon.

    As a side effect of the discussion, GitGitGadget formats checkboxes nicely now.

Developer Spotlight: Bagas Sanjaya

  • Who are you and what do you do?

    I'm Bagas Sanjaya. I'm currently unemployed (due to my autistic condition that makes working formally isn't the nice option for me).

  • What would you name your most important contribution to Git?

    Adding the INSTALL_STRIP variable when installing Git from source (with help from other Git developers due to lack of coding experience).

  • For the benefit of the readers, is it possible for you to elaborate a bit on what the INSTALL_STRIP variable would help them with?

    Typically users install Git from binary package provided by the distribution. For those who wish to install from source, they can install build-time dependencies first, then simply do make && make install. However, it will install Git binaries with debugging info, which can take a lot of space. In addition, many Unix systems have install(1) that has an option to automatically strip debugging info during installation. That's why INSTALL_STRIP is introduced; if supported, users can run make INSTALL_STRIP=-s install to install stripped binaries.

  • What are you doing on the Git project these days, and why?

    I'm mostly translating po strings in recent days. Otherwise I'm hacking on Linux kernel documentation.

  • If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?

    As an autistic man, I'd like to meet developers who can accommodate my special needs (often different from neurotypical people) so that I can thrive my living.

  • It is good to know that you would like to meet compassionate developers. Is it possible for you expand a bit on what you would like to change / enhance in Git when you get a team of such developers for a year?

    I think more on communication. Sure, communicating with email makes life easier for autistic developers (less physical interaction). However, autistic people have different ways of communicating. For me, I need a lot of time to process the information from a mailing list and formulate the wording (which is due to comorbid ADHD). Thus, the community expectation should have been adapted to individual needs, e.g. by being more explicit on explanation of code of conduct when a new developer is contributing. If he/she doesn't understand the CoC, he/she can proactively ask the community about points that he/she doesn't understand.

    In summary, besides adaptation from the community, there must be initiatives from developers themselves.

  • What is your favorite Git-related tool/library, outside of Git itself?

    Gitea. I deployed the server application to the LXD instance on my laptop as repository mirror when I push my favorite repos there.

  • You have experience translating for Git. Is there something that could be done differently to aid with the translation effort?

    I think we need something like self-hosted Weblate to enable anyone with translation skills to easily submit translated strings. But honestly deploying one is tricky; I tried to deploy Weblate but couldn't get strings from Git source code to be available for translation on the interface.

  • How does your mailing list workflow look like?

    Simplicistic. After configuring git send-email to send through outgoing relay of your mail provider and your email clients to send plain text email, unaltered (no line wrapping, intact tabs and spaces), you can contribute by sending patches with the former and reviewing with the latter.

  • What is your advice for people who want to start Git development? Where and how should they start?

    You need to find a joy in application development. If it doesn't makes you enjoy, you may need to take a break or find something else.

  • If there's one tip you would like to share with other Git developers, what would it be?

    As autistic, special interest fascinates me. You need to find one in this project, while staying up-to-date with the general picture.

Releases

Other News

Various

Light reading

Easy watching

  • Understanding Git Flow: A look at the operations of Git Flow through the Flying Logic visualisation of the branches and release process. The channel also has Git visualisations of Collaboration, merge and rebase, detached HEAD, and 'What's a DAG'.

Git tools and sites

  • Sapling SCM is a scalable, user-friendly source control system that supports cloning and interacting with Git repositories, and can be used by individual developers to work with GitHub and other Git hosting services.
  • Stacked Git, StGit for short, is an application for managing Git commits as a stack of patches (with its first release in 2005, it is almost as old as Git itself). StGit was mentioned by Yann Dirson in the Git Rev News Edition #74 developer spotlight.
  • Mergify is a tool to merge changes from a branch one commit at a time, most useful when merging changes to a highly diverged fork of a project.
    • Note that there is also Mergify.com, mentioned in Git Rev News Edition #87, a web service free for open-source projects for automatizing pull requests and securing the code merge using a merge queue.
  • git-mergify-rebase is a replacement for mergify, written using git rebase for better performance, supporting most of features of the original.
  • Nx is a next generation build system for Node.js, with first class monorepo support and various integrations. Listed in the tools section of monorepo.tools, a site mentioned in Git Rev News Edition #84.
  • gitStream by LinearB is a GitHub app that aims to improve the pull request review process.
  • tweets is @bcrypt's janky twitter "replacement", using Git commit messages and GitHub for "microblogging"; see the announcement on Twitter ;-). Written as set of Bash scripts and a Makefile.

Credits

This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Kaartic Sivaraam <[email protected]> with help from Bagas Sanjaya, Bruno Brito, Glen Choo and René Scharfe.