Welcome to the 57th 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 2019.
RFC: Moving git-gui development to GitHub
Pratyush Yadav, a new maintainer for git-gui, asked about whether it is a better idea to use GitHub for development instead of email (after discussion with Dscho), stating arguments in favor and against of moving to GitHub. There were some voices for the idea, and some against, describing additional advantages and disadvantages. One idea was to use GitHub Issues as a centralized issue / bug tracker regardless of where development would take place, which Yadav did.
An interesting vote against the idea was that of Elijah Newren, who wrote that he had been pondering asking the opposite question for filter-repo, i.e. moving its development to git mailing list.
[PATCH 0/9] [RFC] New sparse-checkout builtin and “cone” mode
Last August, Derrick Stolee, who prefers to be called just “Stolee”, sent to the mailing list an RFC patch series to “make the sparse-checkout more user-friendly” and to increase performance in very large repositories.
The patch series achieves that by introducing a new
git sparse-checkout command with 4 subcommands: init, add, list
and disable. The series also introduces the --sparse option to
git clone.
This helps users manipulate how a sparse-checkout is performed compared to the current way.
The performance boost is achieved through a new mode called “cone mode” where all the patterns in the sparse-checkout file are “based on prefix matches at a directory level”. In this mode it can be faster to match the patterns to the files and directories that should or should not be checked out, because a hashset (a set implemented using a hash table) can be used.
Elijah Newren reviewed Stolee’s patches. As Stolee had mentioned that some people have created their own helper tools, Elijah first revealed that he also created a “sparsify” script specific to his company’s internal repository.
Elijah then was concerned about how the feature worked along with
worktrees and how the add
subcommand and the cone mode worked. He suggested that the
core.sparseCheckout config option could be tri-state to make it
explicit how the sparse-checkout file should be parsed.
Eric Sunshine also chimed into the discussion.
Stolee replied to Elijah that he hadn’t considered worktrees and was
going to take a look at them. He accepted the suggestions about how
add should work and about making core.sparseCheckout a tri-state
and then sent a
V2 version of the patch series
with those changes and a few other improvements.
The add subcommand was also replaced with a set
subcommand, and the tri-state was actually implemented by adding a
new core.sparseCheckoutCone config option.
The discussion continued between Stolee and Elijah, mostly about the documentation and commit messages. Then Stolee sent a V3 version of the patch series with small bug fixes and various improvements, especially in the documentation and commit messages according to Elijah’s suggestions.
After another round of review from Elijah, Stolee sent a V4 version of the patch series with only a few small changes.
Then Gábor Szeder commented on few bugs and small things he had found; Jon Simons and Elijah also made a few comments. So Stolee sent a V5 version of the patch series on October 21st addressing the comments.
Phillip Wood, Stolee and Junio Hamano then discussed another small issue. It seems though that the patch series will be merged into the next branch soon.
Who are you and what do you do?
I’m a physicist by training, unfortunately I had to stop working some years ago due to a chronic health condition. Since then I’ve spent some time coding and I got into contributing to Git after using it on another open source project.
What would you name your most important contribution to Git?
That’s hard to say. Personally it was getting rebase -i to create
commits without forking git commit. I think it was my first big
contribution, it gave a noticeable performance improvement and
meant learning the API around commit creation as well as getting to
grips with the sequencer code that drives cherry-picks and
interactive rebases.
What are you doing on the Git project these days, and why?
I’m still mostly working around the code in the
sequencer. Interactive rebases are one of the features I like best
about Git. Being able to rewrite commits in order to polish a
feature before merging it or posting patches helps make it easier to
understand and review. I’ve also contributed to add -p and
diff --color-moved-ws as I find those really useful as well.
I also try to spend some time reviewing patches in the areas I’m interested in. One of the great things about contributing to Git is the reviews one receives when posting patches, they’re always friendly and constructive and I try to do the same for others. It’s also interesting to see what problems other people who use Git are facing and how they’re solving them.
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?
Gosh that would be fantastic. I’d probably concentrate on the
UI. Firstly I’m interested in being able to amend commits more
easily by providing a simpler interface to rebase -i that does not
involve editing a todo file. I’m currently working on a script that
lets you amend the commit that created the current line directly
from an editor and lets you walk backwards and forwards through
history rewriting it as you go. Being able to say “amend the commit
responsible for this line” with a single key stroke is really
convenient.
There are a number of other UI related projects I’m interested in. I
use diff-highlight but wish it would work on hunks with different
numbers of additions and deletions. Adapting it to diff the diff in
order to highlight the changes would be useful but would need some
careful heuristics to distinguish between when highlighting the
changes is useful and when it is just confusing. Another diff
improvement I’d like to see is implementing --color=porcelain for
git diff that would allow apps like tig and magit to show
moved lines.
I’d also like to improve git push and git pull to extend the idea of
--force-with-lease to support synchronizing between a laptop,
desktop and remote server by allowing forced updates of the local
branch when it has not changed since it was last pushed and improve
push --force-with-lease to default to using the hash of the last
pushed commit.
If there’s still some time left then working on the documentation to
make it more approachable for new users would be great. At the
moment the man pages detail the individual commands but there’s not
much documentation introducing high level concepts and ideas. There
are some other things such as adding a --reword option to commit
and improving add -p to allow the selection of groups of lines but
that’s probably enough for now.
If you could remove something from Git without worrying backwards compatibility, what would it be?
Personally I’d like to change the way ignored files are handled so
that Git never overwrites them (we could add a new category for
files that are expendable). The relative priority of .gitignore
and .git/info/excludes could also be tweaked.
Standardizing option names across the commands would also help users I think.
What is your favorite Git-related tool/library, outside of Git itself?
I use tig for inspecting history with log and blame. I also
use Public Inbox a lot for searching
the mailing list.
Various
Welcome to Kaartic Sivaraam to the Git Rev News edition team! And thanks to Gabriel Alcaras, who leaves the team after contributing to the interviews and as the author of the script that scrapes some websites to help prepare the “Releases” section.
Emily Shaffer announced the new git-mentoring@googlegroups.com mailing list as “a great place for those who are new to Git and interested in learning how to contribute to ask questions and expect kind, thorough answers out of the spotlight of the main Git mailing list”.
GitHub announced GitHub Archive Program, intended to preserve open source software for future generations in partership with Long Now Foundation, the Internet Archive, the Software Heritage Foundation, Arctic World Archive, Microsoft Research, the Bodleian Library, and Stanford Libraries. On February 2, 2020, GitHub will capture a snapshot of every active public repository, to be preserved in the GitHub Arctic Code Vault. This data will be stored on 3,500-foot film reels.
It looks like the Git Merge 2020 conference will be in Los Angeles on March 4 2020.
Light reading
Highlights from Git 2.24 on GitHub Blog by Taylor Blau: feature macros, commit graph by default, adopting the Contributor Covenant (see previous Git Rev News), recommending new history-rewriting tool: git-filter-repo (more about which can be found in Git Rev News #54), and other.
Updates to the Git Commit Graph Feature by Derrick Stolee
describes new commit-graph related changes in Git version 2.24.0:
new faster algorithm for topological sorting (e.g. for git log --graph),
namely an iterative version of Kahn’s algorithm (making use of generation numbers),
incremental commit-graph format with adaptive merging,
new fetch.writeCommitGraph setting to update commit-graph after every git fetch,
and having core.commitGraph and gc.writeCommitGraph on by default.
See also this Twitter thread.
Previous blog posts in the series about commit-graph were linked to in Git Rev News Edition #41, #45 and #51. Developing incremental commit-graph was covered in detail in Git Rev News Edition #52. At the time of writing link to mentioned article was not yet posted to Derrick Stolee developer homepage.
[LWN.net] Next steps for kernel workflow improvement by Jonathan Corbet: fix attestation with minisig, add base-tree information, and going beyond email.
[LWN.net] Analyzing kernel email by Jake Edge, about research which goal is “formalizing and assessing the Linux kernel development process”.
I posted my password / API key on GitHub. Now what? by Flavio Copes. There are various tools to detect such situation, and/or to safely store secrets in Git repository; some links can be found for example in Git Rev News #39.
Three Simple Rules for Putting Secrets into Git by Jesse Swidler (2018), author of LockGit.
“Stupid git commit-tree tricks” series of blog posts by Raymond Chen, starting with Part 1: Building a commit manually out of a tree.
My favourite Git commit by David Thompson.
How to write a kickass README by James.Scott (@scottydocs).
What nobody tells you about documentation, namely that it needs to include and be structured around its four different functions: tutorials, how-to guides, explanation and technical reference, each of which requires a distinct mode of writing.
Git tools and sites
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 Phillip Wood and Andrew Ardill.