Welcome to the 51st 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 April 2019.
GSoC students and mentors 2019
Two students are going to work on Git during this summer as part of the GSoC (Google Summer of Code):
Matheus Tavares is going to work on making pack access code thread safe. He will be mentored by Olga Telezhnaia, a former Outreachy intern, and Christian Couder. Matheus has prepared a blog to report about his experience.
Rohit Ashiwal will work on improving consistency of sequencer commands. He will be mentored by Thomas Gummerer, a former GSoC student, and Elijah Newren. Rohit has also prepared a blog to report about his experience.
It will be the 12th time that the Git project will mentor students as part of the GSoC. Rohit and Matheus will be the 28th and 29th students mentored since 2007 when Git started participating in the GSoC.
It will be the 15th year of GSoC and to celebrate that Google decided to have the GSoC Mentor Summit 2019 in a hotel in Munich, Germany instead of a Google campus in California. The Mentor Summit will last 3.5 days (Thursday, October 17 - Sunday, October 20) instead of the usual 2.5 days. The additional day, Friday, October 18, will be “Fun Day Activities for attendees to explore Munich and get to know each other before the unconference begins”.
[RFC PATCH] *.h: remove extern from function declarations
Denton Liu sent a big RFC patch that removes extern keywords in
front of function declarations and that affects ‘.h’ header files
in large numbers.
He said that he used the following command to remove the keywords:
$ git ls-files '*.h' | xargs sed -i'' -e 's/^\(\s*\)extern \(.*(\)/\1\2/'
And the following one to check the result:
$ git grep -w extern '*.h'
Jeff King, alias Peff, replied that dropping extern should not be
done on function pointer declarations though, as a function pointer
is a variable, so its visibility would change if extern is removed
in front of it.
Junio agreed with Peff and explained that the reason we avoid wholesale updates “is because of an unnecessary bug like this one, not the one-time conflict resolution load that can be subcontracted out to ‘rerere’ once dealt with ;-)”.
Junio also suggested using “a tool more suited for the job (e.g. spatch)” as it “raises the confidence level of the end result a lot more than a ‘sed and then eyeball’ rewrite”, though we then have to be careful about possible “bugs in the instructions we give to the tool”.
Denton then sent a second version of his work. It was now a 3 patch long patch series.
The first patch used the spatch tool to do most of the extern
keyword removals. The second patch still used sed to do it where
spatch didn’t work, but it made sure to ignore function
variables. The third patch used a Coccinelle script to make sure
that no more extern keywords are added to the code base.
Thomas Gummerer replied to the first patch that it “leaves a bunch of oddly indented parameter lists behind”, as when a function has a larger number of parameters, its declaration often spans more than one line.
Denton then send a third version of his work, with an additional patch to “manually align parameter lists that were mangled by the tools”.
Peff replied wondering if it was a good thing to modify files in the compat/ directory as the code there is often “copied from elsewhere”. He also wondered if it was worth keeping the Coccinelle script as it is expensive to run.
In the fourth version
of his work, Denton decided to keep the Coccinelle script, but
excluded the compat/ directory from the files where extern is
removed.
Junio noticed that in a commit message Denton mentioned using:
$ git ls-files \*.{c,h} | \
grep -v ^compat/ | \
xargs sed -i'' -e 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/'
and then asked him to remove the useless backslashes at the end of the first 2 lines above, saying:
Your shell knows its own syntax sufficiently well, and when you end a line with a pipe, it knows that you haven’t finished speaking to it and waits for you to give the command downstream of the pipe, without being told that you haven’t finished with a backslash.
Unfortunately Gábor Szeder then found that the Coccinelle script failed on ‘compat/obstack.h’ as it is included in a ‘.c’ file checked by Coccinelle scripts.
Denton replied by proposing to drop the patch that contained his Coccinelle script, but Johannes Schindelin, alias Dscho, suggested to exclude certain directories or certain files for certain Coccinelle scripts.
There was then a long discussion thread involving Peff, Denton, Jacob Keller, Dscho, Junio and Gábor about what was possible to do with Coccinelle and spatch and how they are used in the Git toolchain. This thread eventually resulted in Peff writing a small series of patches, based on a previous patch by Jacob, that makes it possible to run Coccinelle faster on machines with a lot of memory. Peff’s patches have since been merged into the ‘master’ branch.
Denton in the meantime sent a fifth version of his work that drops the patch that contained his Coccinelle script, and loses the useless backslashes. This patch series has also been merged into the ‘master’ branch and will be part of Git v2.22.0 that should be released at the beginning of June 2019.
Who are you and what do you do?
My name is Denton and I’m a relatively new contributor to Git. I’m a Software Engineering student at the University of Waterloo and I’ve been bouncing around from internship to internship until I graduate next year.
I got started just over half a year ago when we had an assignment in school that required us to make a contribution to some open-source project. Since Git is so ubiquitous for developers, my team decided to target it.
Since then, I never really stopped because I’ve been having a lot of fun with it.
What would you name your most important contribution to Git?
I haven’t really been as prolific as other contributors so I wouldn’t
say that my contributions are “important”, per se. I guess the most
important contribution that I’ve made (although it’s still cooking) is
teaching --keep-base to rebase.
Judging from the number of StackOverflow posts about it, I guess people expect this to be a feature but, since it’s not, I think most people alias it away or something.
Hopefully, this will be helpful to all the good people in the world who bother to clean up their branches before sending them up ;).
What are you doing on the Git project these days, and why?
I’d say that I’m a “selfish” contributor to Git. What I mean by this is I’ve only been working on features that I’ve wanted.
I keep a todo list on my phone of feature requests that I would like in Git and, whenever I have some free time, I’ll code it up. So these days, I’m mostly working all over the place, but mostly at a pretty high level.
Why? Because it’s fun :). It’s always cool running
git pull upstream master and seeing your work in there.
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?
Hmm, it would be nice if Git’s interface were a little more standardised.
If I could get a team of developers working on Git, I’d probably get them to clean up Git’s user interface and make it more consistent with itself.
In this regard, Duy has been making me happy with his work making Git externally and internally consistent with git-restore, git-switch and the diff-parseopt changes but if we could have a team of Duys working, that would be amazing!
If you could remove something from Git without worrying about backwards compatibility, what would it be?
Continuing the above, my biggest gripe about Git is how inconsistent its
interface is since it was developed organically. I think the biggest
example of this would be how the meaning of .. and ... are
essentially swapped in diff compared to the log family of commands. I
always end up using the wrong number of dots because of this.
If I could change one thing about Git, it’d probably be the above. Even though it’s a very small thing, it trips me up a lot of the time.
What is your favorite Git-related tool/library, outside of Git itself?
I like to keep my setup as vanilla as possible so that when I move onto other machines, I don’t have to adjust my workflow very much so I only really use the stock Git. However, a while back, I was reading about git-imerge by Michael Haggerty.
I’m very thankful that I haven’t had to deal with any painfully large merges recently that have necessitated it but I’m keeping this tool in my back pocket in case the situation ever comes up.
Anything else you’d like to add?
I’d like to thank the more seasoned members of the Git project for being patient and helping me learn even through the (many) mistakes I’ve made through the process. In particular, in no particular order, I’d like to thank Junio, Ævar, Phillip Wood, Johannes Schindelin, Eric Sunshine and many others for helping me.
Various
Git and the new SHA-1 prefix collision attack is an email by Ævar Arnfjörð Bjarmason that has information and links about a newly published paper about new attacks building on the known “SHAttered” attack.
On April 1st, Ævar sent a two patches long patch series to the mailing list. These April fool’s day patches were “praise: a culturally sensitive wrapper for ‘blame’” and “praise: make ‘blameless’ cultural enforcement configurable”.
Dave Borowitz, one of the top contributors of Gerrit Code Review, leaves the project after 9k reviews, 3.4k commits and 8 years of contributions.
Someone Is Hacking GitHub Repositories and Holding Code Ransom, which lead to Git ransom campaign incident report—Atlassian Bitbucket, GitHub, GitLab; this topic was also discussed on git mailing list: Git ransom campaign incident report - May 2019.
Light reading
Exploring new frontiers for Git push performance
includes a description of the new “sparse” push algorithm, enabled
by the pack.useSparse config option.
The Developer Homepage of Derrick Stolee contains a number of interesting articles, presentations and links especially about features he developed like the commit-graph.
The history behind 6 years of development of Gerrit v3.0 goes back in time and describes the long path from the original greenish GWT UI until the latest shiny blue Polymer-based user experience.
git rebase in depth, a guide to help demystify the powerful git-rebase.
Signing Git Commits by Kyle Rankin, from Linux Journal.
Git does not remember username and password on Windows by André Snede Kock, or how to use Windows Credentials manager with Git, and how to manually set credentials if needed.
Stupid git tricks: Combining two files into one while preserving line history by Raymond Chen; the trick is to create a rename/rename merge commit.
The Essential Git Handbook by Sanjula Madurapperuma, teaching a little about Git.
Squash commits when merging a Git branch with Bitbucket by Abhin Chhabra.
Serving Vue.js apps on Github Pages by Muhammad Usman; the trick is to configure GitHub Pages and use ‘docs’ folder.
Git tools and sites
gitfolio: personal website + blog for every GitHub user (JavaScript with Node.js); see https://imfunniee.github.io/gitfolio/.
GitHub Learning Lab: learn new skills by completing fun, realistic projects in your very own GitHub repository.
fh: record changes to a file on a per-file basis, with ed(1), diff(1), awk(1), sed(1) and sh(1).
commit-messages-guide: a guide to understand the importance of commit messages and how to write them well.
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 Gabriel Alcaras <gabriel.alcaras@telecom-paristech.fr> with help from David Pursehouse, Luca Milanesio and Denton Liu.