Welcome to the fourth 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 May 2015.
At the Git Merge 2015 conference, during the Contributor Summit, there were discussions about how to help people send patches to the Git mailing list.
Properly sending patches to the mailing list is not easy in the first place because email clients these days tend to heavily reformat the content they send. This reformatting, which may include word-wrapping the text, making it quoted-printable, adding MIME parts or replacing tabs with spaces, will in most cases make inlined patches sent to the Git mailing list impossible to apply or even review.
That’s why the SubmittingPatches documentation file has a long explanation to help people send patches which starts with:
Learn to use format-patch and send-email if possible. These commands are optimized for the workflow of sending patches, avoiding many ways your existing e-mail client that is optimized for “multipart/*” mime type e-mails to corrupt and render your patches unusable.
git send-email is indeed the best way to send emails to the mailing list once it has been properly configured. The problem is that it is not very easy to configure to say the least, especially on Windows.
A recent discussion on the mailing list shows how difficult it can be even for developers to find a way to properly send a patch to the mailing list. Toward the end of the discussion, Stefan Beller summarized the discussions at Git Merge 2015 this way:
This workflow discussion was a topic at the GitMerge2015 conference, and there are essentially 2 groups, those who know how to send email and those who complain about it. A solution was agreed on by nearly all of the contributors. It would be awesome to have a git-to-email proxy, such that you could do a git push
master:refs/for/mailinglist and this proxy would convert the push into sending patch series to the mailing list. It could even convert the following discussion back into comments (on Github?) but as a first step we'd want to try out a one way proxy. Unfortunately nobody stepped up to actually do the work, yet :(
A few days later, Roberto Tyley, who is the author of the BFG repo-cleaner, replied to Stefan’s email by announcing submitGit:
Hello, I’m stepping up to do that work :) Or at least, I’m implementing a one-way GitHub PR -> Mailing list tool, called submitGit:
https://submitgit.herokuapp.com/
Here’s what a user does:
- create a PR on https://github.com/git/git
- logs into https://submitgit.herokuapp.com/ with GitHub auth
- selects their PR on https://submitgit.herokuapp.com/git/git/pulls
- gets submitGit to email the PR as patches to themselves, in order to check it looks ok
- when they’re ready, get submitGit to send it to the mailing list on their behalf
All discussion of the patch stays on the mailing list - I’m not attempting to change anything about the Git community process, other than make it easier for a wider group people to submit patches to the list.
This announcement was met with a lot of enthusiasm from the community, especially from the Git for Windows developers. Junio Hamano, the Git maintainer, also liked the idea and pointed out that submitGit would be usable for an even wider audience if it only required a narrower scope of GitHub authorization, which submitGit was updated to reflect a few days later - improvements are still coming!
Aspiring contributors are encouraged to try submitGit out, and provide feedback on the mailing list or on the project’s GitHub issues.
git-multimail resurrected! (written by Matthieu Moy)
git-multimail got a new co-maintainer, and is active again after a long period of inactivity. A summary of the recent activity was posted on the Git mailing-list. A 1.1 release is expected in June. Don’t hesitate to join the fun and help by reviewing pull-requests or submitting new ones!
Jim Hill noticed that Git issues an error message saying that copy_fd() was given a bad
file descriptor when clean/smudge filters is fed an file with empty contents, found that
the problem was caused because an in-memory contents that was empty was passed (by mistake)
as NULL, instead of an empty string "" in this codepath, but the NULL was used as a
signal to tell Git to instead read from a given file descriptor. The fix was trivially
correct and was applied.
The new test script, however, exhibited a flaky behaviour. Sometimes it passed, sometimes it saw EPIPE. Peff observed:
Hmm, I thought we turned off SIGPIPE when writing to filters these days. Looks like we still complain if we get EPIPE, though. I feel like it should be the filter’s business whether it wants to consume all of the input or not[1], and we should only be checking its exit status.
[1] As a practical example, consider a file format that has a lot of cruft at the end. The clean filter would want to read only to the start of the cruft, and then stop for reasons of efficiency.
The discussion lead to an enhancement to allow clean/smudge filters to quit before reading their input fully.
Christian Halstrick said that he sometimes gets “invalid channel 101” errors when pushing over HTTP using a JGit client.
He had already debugged the problem and noticed it only appeared when quotas on the filesystem prevented the Git server from storing a big packfile. In these cases, the server sends back a packet line “0013error: …” to the client; but the client, thinking the sideband communication should still be used, interprets the “e” from “error” as a channel number. The ascii code of “e”, which is 101 in decimal, is the reason why the error is “invalid channel 101”.
Christian asked a few questions to get more information about when sideband communication should happen and how a server should respond in case of error.
As Shawn Pearce had developed both the Smart HTTP protocol, which is now the most commonly used HTTP protocol by Git clients and servers, and JGit, the implementation of Git in Java, he answered those questions with a lot of details and further nailed down the problem:
The bug here is JGit’s ReceivePack/BaseReceivePack code not setting up the side-band-64k early enough for this failure report to be wrapped in it.
And Shawn concluded with the following:
FWIW I am glad you found this. I have been chasing this bug for years but couldn’t really pin it down to anything. If its the “pack won’t fit on local disk due to disk full” condition that narrows down the offending section of JGit considerably.
Bastien Traverse was having trouble specifying the date when creating a commit
with the --date parameter to git commit command. He tried various
formats, e.g. git commit --amend --date="2015-05-21 16∶31 +0200"
and got the date right but not the hours and minutes.
Peff tried to reproduce it (as the --date=<string> parsing was recently
corrected, there was a possibility of regression), but he couldn’t. It
turns out that the input Bastien was feeding did not have the right “colon”.
Your “colon” is actually UTF-8 for code point U+2236 (“RATIO”). So git’s date parser does not recognize it, and punts to approxidate(), which does all manner of crazy guessing trying to figure out what you meant.
Git 2.4.1 and 2.4.2 maintenance releases.
Together with Git 2.3.8, git commit --date=now now works correctly in timezones that honor
daylight-saving-time, fixing a
breakage Linus noticed.
We are nearing the Git 2.x release for Windows. Project maintainer, Johannes Schindelin, wrote the following:
There are 32-bit and 64-bit versions both of regular installers and portable installers (“portable” meaning that they are .7z archives that can be unpacked anywhere and run in place, without any need for running an installer).
My projected time line is to hammer out the last kinks until Friday, and then continue after a one-week leave, if needed, and then finally retire msysGit and start the official 2.x release cycle of Git for Windows.
Other releases:
Various
Light reading
Git tools and sites
GIT_COMMITTER_DATE of the most recent commit until the SHA matches a particular pattern :)This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com> and Nicola Paolucci <npaolucci@atlassian.com> with help from Junio C Hamano, Matthieu Moy, Emma Jane Hogbin Westby, Roberto Tyley and Mikachu.