Welcome to the 106th 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 months of November and December 2023.
[PATCH 0/4] Switch links to https
In September, Josh Soref posted a 4-patch series on the mailing list to improve the URLs used throughout the documentation and the code base of the project.
The main goal was to use HTTPS instead of HTTP in the URLs to improve user security, but along the way some patches replaced URLs that didn’t work anymore with some new ones pointing to the same content.
Eric Sunshine replied to Josh’s patches asking why one URL was
changed from http://json.org/ to https://www.json.org/ instead
of just replacing http with https. Josh replied that it was
because that website was self-identifying with the latter URL using a
meta refresh.
In the meantime, Junio Hamano, the Git maintainer, replied to some
patches saying that it might not be worth updating some URLs, either
because it was clear from the context that they were old, or because
they were part of some code we borrowed from other projects. In some
cases, they were an argument of a Git command and still just worked,
while the meaning of the command changed a bit when http was
replaced with https. Junio liked the fact that some broken links
were fixed by the series though.
Josh then sent a version 2 of his patch series. This took into account Eric’s comments as a commit message was improved to say that some changes were made to respect a site’s self-identification. Junio’s comments were also taken into account as a number of URLs that were previously changed were now left as-is.
Elijah Newren and Junio commented on this new version. They both suggested improving commit messages or the cover letter of the series to better explain the reasons for the changes that were made. In one case, Elijah and Josh discussed replacing the URL of a website that seemed to be often down with a link to its content on the Internet Archive.
In November, Josh then sent a version 3 of his patch series where the first and second patches had been swapped to avoid some confusion for reviewers who would ask why some URLs weren’t changed in the first patch overlooking that the second one would change them.
The other significant change compared to version 2 was that Josh decided not to replace the URL of the website that was often down saying “we’ll risk users getting hacked content from an arbitrary MITM instead of taking archived authenticated content based on the last time their web site was properly maintained”.
Elijah replied that he would be fine with using the archived link if it was better justified in the commit message, but said that he also agreed with merging the whole series as-is, as he had checked all the links and they all looked good to him.
Josh replied he could come back later to change the URL and preferred the series to be merged as-is. He thanked Elijah for taking the time to re-check every link, saying he knew exactly how tedious that is.
Junio agreed with merging the series, which is now part of the ‘master’ branch.
VonC is a prolific contributor to the Git topic on Stack Overflow. This edition features an interview with him. Thanks to our survey respondents for suggesting to interview VonC!
Who are you and what do you do?
By day, I am an information technology consultant working for a computer services company in France. By night, I am VonC on Stack Overflow, and I have contributed to various topics since its early days (Sept. 2008). I do that every single day. It includes answering questions about Git: almost 16K answers in 15 years.
What would you name your most important contribution to Git?
I do not contribute to Git directly, but I report on Stack Overflow any interesting git/git commits which provides a new answer to old questions.
I started in 2012 with questions like “Squash the first two commits in Git?” and “How do I remove a submodule?”. Then 1630 commits followed over the next decade.
Why answering questions about Git on Stack Overflow?
As I mentioned in “How to earn a million reputation on Stack Overflow: be of service to others”, by Ryan Donovan, this is a way to give back to the community, and to learn in the process.
I learnt Git itself even before installing it, by answering a few questions on Stack Overflow, as I detailed in “How’d you get started?”.
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?
I mentioned in 2013/2016 the issue of storing large files in Git repositories.
But nowadays, I would work on the workflow side of Git, and how to make it easier to use for beginners. I follow GitButler and Scott Chacon’s work.
GitButler is rethinking everything between when you write code in your editor of choice and when you push that code to GitHub for review. Why are you making ‘wip’ commits when your SCM should be recording everything for you? Why are everyone’s commit messages close to useless? Why is
git blamethe best way to get context on the code your team has written? Why can’t you seamlessly transition work between computers?
If you could remove something from Git without worrying about backward compatibility, what would it be?
git checkout! It is time. As I explained in 2020,
the git switch/git restore commands are “experimental”
in name only, and are here to stay.
What is one of your most favorite features of Git?
Coming from CVS/SVN, one of my favorite features of Git is its powerful
branching and merging capabilities. Branches in Git are lightweight and
switching between them is fast, making it convenient to manage multiple
streams of work simultaneously (and you have git worktree
if you want to preserve your current working tree).
I use those branches and merges with “gitworkflow” (one word),
using long-lived integration branches (like “master/main/release”),
and “ephemeral” integration branches (like “public/next/devel”,
created for a specific release cycle, then deleted and recreated for the
next release cycle). See more at “gitworkflow workflow”
and “Handle Git branching for test and production”.
What is your favorite Git-related tool/library, outside of Git itself?
I often used github.com/github/gitignore
(“A collection of .gitignore templates”). I have also used and promoted
git filter-repo, to
remove large files from a Git repository.
Could you brief a bit about one of your most memorable experiences with Git?
My first git clone.
As mentioned in “How to earn a million reputation on Stack Overflow: be of service to others”, at the time I stumbled upon Git (2008/2009), I was managing big Rational ClearCase repositories of terabytes of data. The idea of cloning a full (Git) repository on my laptop was… incongruous, to say the least!
I am aware of the debate around monorepo vs. multirepo (which sometimes goes in hand with the debate around monolith vs. microservices), but I found in the subsequent years that working with multiple small Git repositories was much more manageable than working with a single large one, as I used to do before, using huge ClearCase VOBs.
What is your advice for people who want to start using Git? Where and how should they start?
Start with understanding Git branching, and operations around branches (switch, merge, rebase, cherry-pick).
For that, I always redirect people to “Learn Git Branching”
(learngitbranching.js.org): nothing to install, all exercises are done
directly in the browser, and it is very visual.
I also discourage people from blindly following the “Git Branching Model”,
where an integration branch like develop is merged to another integration
one like master. See the links above for “gitworkflow” where I explain
why one should merge to an integration branch, not from it: merging from
it means you are merging everything currently integrated into that branch.
If you want to “exclude” some of those integrated commits, that becomes a
nightmare to manage.
There’s a common conception that “Git is confusing”. What are your thoughts about the same?
Right… you mean XKCD 1597, Oct. 2015, “Git”.
The level of integration of Git in IDEs (like Eclipse, IntelliJ, VSCode, …) has made Git more accessible to beginners. I often redirect them to a combo VSCode + GitLens, and that is enough to get them started.
As long as the workflow is clearly defined, and the rebase is understood,
for managing pull request
(you rebase your local feature branch on top of the target branch,
before force pushing it to the remote repository, with lease
or if-includes), the users
manage to get by. The bulk of my training is about the PR (Pull Request)
workflow, which involves git rebase (--onto), and
git push --force-with-lease or --force-if-includes.
But clarifying why Git exists, and where it comes from (I have younglings who have no idea who Linux Torvalds is, and his role in the creation of Git) can help. Git comes with a certain vision of how a VCS should work, and it has a lot to do with the way the Linux kernel is developed.
If there’s one tip you would like to share with other users of Git, what would it be?
Stop using git checkout, start using git switch/git restore instead!
Editor’s note: We hope you enjoyed this interview. We’ll explore if we could interview other such contributors who don’t directly participate in the mailing list. If you have any suggestions, you’re most welcome to share them with us through our issue tracker or by writing an email to <kaartic.sivaraam@gmail.com>.
Various
Light reading
HEAD and headsEasy watching
Git tools and sites
git-latexdiff is written as a BSD-licensed Bash script,
while latexdiff is written in Perl (and is GPLv3-licensed).
The git-latexdiff tool was mentioned in passing in
Git Rev News Edition #8.git history
(also known as “Stop merging master”) by Mark Jason Dominus (the author of the tool),
from 2013.dat command line tool to share files with version control,
back up data to servers, browse remote files on demand, and automate long-term data preservation.
Written in JavaScript for running with Node.js.This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from VonC, Josh Soref and Štěpán Němec.