Discussions

Reviews

Lars Schneider wrote that to avoid breaking tests in the future he
configured Travis-CI to run all Git tests including git-p4 and git-lfs
tests on both Ubuntu and MacOS using gcc and clang.

If his config was enabled on https://github.com/git/git then the
status of all official branches and all pull requests could be known
by any contributor for free.

Junio, the Git maintainer, replied that the last time he looked at it,
Travis wanted write access to the repository, and that for security
reason he could not allow that.

Dennis Kaarsemaker replied with the following:

It does not need write access to the git data, only to auxiliary
GitHub data: commit status and deployment status (where it can put
“this commit failed tests”), repository hooks (to set up build
triggers), team membership (ro) and email addresses (ro).

Then a lot of long time members of the community, like Jeff King,
Johannes Schindelin, Shawn Pearce, Stefan Beller, Roberto Tyley, Luke
Diamand and Sebastian Schuberth, started discussing if it would be
better for Travis to be configured only on a fork of git/git and about
the annoyance that emails sent by Travis might be.

Roberto Tyley, the author of submitGit,
then talked about possible enhancement to the submitGit workflow if
Travis or another CI system are set up, like enabling sending a patch
email to the Git mailing list only after the test results are
available.

And then Matthieu Moy explained the benefits for everyone like this:

The very nice thing with Travis-CI is that it does not only test the
repository’s branches, but also all pull-requests. So, if it is
activated on git/git, it will become possible to have a flow like

1) User pushes to his own repo, sends a pull-request,

2) Travis-CI notices the pull-request and builds it (no action needed
from anyone),

3) Once the build is finished, the user can use e.g. SubmitGit to
actually submit the code.

This has real benefits for the submitter (know if your code is broken
early), for the reviewers (things like “you have a def-after-use” would
be noticed by a computer before human beings start spending time on the
review), and for you (some issues noticed before a topic enters pu).

There’s no extra work for the user at all compared to the standard
pull-request flow (nothing to do, just submit a PR), and a one-time
setup for the project.

This appear to have convinced Junio of the value of a CI tool linked
to git/git, and Lars has since posted
a version 2
and a version 3 of his
patches,
so an interesting way to test patchs will perhaps be available soon
to Git developers.

Support

the format of the comment lines in a rebase instruction sheet has
become stricter - it could no longer begin with spaces or tabs. The
comment char (“#” for example) has to appear on the first column.

and that this change broke his script.

As Matthieu Moy found out, the cause of the regression was a patch to
pre check the rebase instruction sheet before starting an interactive
rebase. The goal of this pre checking patch was to avoid discovering a
syntax error in the instruction sheet in the middle of a rebase.

Matthieu then posted a patch to fix the regression
based on a suggestion by Junio Hamano. Matthieu’s patch just
prefilters the instruction sheet by piping it through
sed 's/^[[:space:]]*//'.

But Junio replied that Matthieu’s patch would fix one aspect of the
problems caused by the pre checking patch. There could be more
problems as the pre checking code is different from the actual parsing
when the instruction sheet is processed. Junio also said he was
tempted to revert the pre checking patch, but he provided a patch to
fix the problem anyway by using the same code in both the pre checking
step and the actual parsing.

Matthieu agreed that Junio’s patch was the way to go, and after a few
more patches and emails, they agreed on a solution.

Developer Spotlight: Luke Diamand

Q. Who are you, and what do you do?

A. I’ve been writing software since my uncle got me hooked with a TI-56
calculator and a TRS-80 model 2. Right now, I’m working for Roku,
(making cool new video streaming hardware :-) which currently involves
a lot of fairly low-level digging around in SoC software.

Q. What would you name your most important contribution to Git?

A. My fix to git-p4, to make it stream commits into fast-import,
rather than buffer them all up in memory first. I did it out of
desperation.

At the time, I’d just been working for a tiny startup which was also
making video streaming products, but sadly not making any
profits. While there, I’d become hooked on git after watching “those”
videos.

So when I found myself at Broadcom in about 2008, and started trying
to use Perforce, almost the first thing I did was try to use
git-p4. But at the time, it read everything into memory using an
O(n^2) algorithm, which meant it would use up all of the swap space
available (no matter how much you had) and then crash after a couple
of days.

These days of course, if you’ve got a problem the answer is on
stackoverflow (if you can think of it, it’s already been done) but
back then, we had nothing like that. Eventually I found a patch from
Andrew Oakley which hinted at the solution. Inspired by this, I taught
git-p4 to stream commits at fast-import (as the writers of fast-import
presumably intended) and suddenly I could use git at work. Which was
completely awesome!

With a good deal of help from Pete Wyckoff and Junio I then got it
submitted; that process itself was a massive eye opener as to how to
really review code (and how to write shell script as well).

I spent the next few years trying to encourage everyone else in the
office to use git and submitted a few more patches to git-p4 along the
way. We finally switched over, and then the office was closed down!

Which is how it is I now find myself working side-by-side with the
very same Andrew Oakley who wrote that original patch - he’s now at
Roku as well!

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

A. It’s all git-p4 related. I’ve got a tiny fix that lets you work on
a detached head; that’s just waiting for a bit of bandwidth.

After that, there’s a few things I’ve thought about. It would be very
handy to be able to turn a P4 shelved changelist into a git commit
(and vice-versa). And I think it ought to be possible to teach git-p4
to act in a “daemon” mode, whereby it gets notified of changes and
automatically pushes them into Perforce, and pulls Perforce changes
back into git. I’ve had something like that going in the past but it
was an ugly hack.

A. 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?

Performance on big repos would be nice. Quite a few people have tried
in the past so maybe it’s just impossible, but for example, I did
wonder if more could be done with cache prefetching (pld instruction
on ARM) to slurp data into the cache faster. Since I’m pretty much
completely ignorant of the internals of git, I’m able to be free of
the boring constraints of reality :-)

And I’d really like a way to painlessly teach people to use git who
only know about traditional revision control systems (e.g. Perforce).

Q. If you could remove something from Git without worrying about
backwards compatibility, what would it be?

I think Junio already removed it. That “feature” where git push would
push all of the branches rather than just HEAD. It had me completely
confused when I was first starting.

I really like Gerrit, although the prolog configuration makes my head
hurt. And of course Github has to get a mention - it’s making git (and
hence sane version control) ubiquitous. There was a question about it
the other day on a mountain bike forum I follow!

Q. What is your favourite new feature in git?

git commit --fixup

I only found this recently, it’s just brilliant. Thank you, whoever it was put that in!

BFG 1.12.5 adds support for converting a repo’s history into the new Git LFS format, so even old files in Git history can be transferred into Git LFS, reducing repository size.

git-multimail 1.2.0 adds among others the possibility to filter out branches for which no emails should be sent, HTML colored emails, Gerrit and Atlassian BitBucket Server support.

Other News

Updates

Since we talked about it last month David Turner
submitted a new patch series of his work on
alternate ref backends. This work is being reviewed by Michael Haggerty, Junio, and others. The ultimate goal
is still to allow a lmdb-based backend, which should be faster and have fewer issues on
case-insensitive filesystems than the traditional files-based backend. This work is sponsored by
Twitter.

Various

The GitMinutes podcast finally published the last episode from the Git-Merge conference. Here are all five parts in a neat overview: