Nearing the end of 1.7.3 cycle

I just tagged and pushed out 1.7.3-rc2; you can get it from the usual places.

During this cycle, which lasted for about two months, we added a little shy of 500 changes to the system. contributed by 74 people, among which 18 were new contributors. This brings the total contributor count to 790.

The last cycle (1.7.2) was about three months long, with 530 changes from 93 contributors, among which 28 were new, but this probably does not mean that we have accelerated recently; it is more of an artifact that I switched jobs and had to move during the last cycle.

  • Current Mood
    reasonably happy
  • Tags

User's survey 2010

Relaying Jakub Narebski:

The Git User's Survey 2010 is now up! Please devote a few minutes of your time to fill out the simple questionnaire; it'll help the Git community understand your needs, what you like about Git (and what you
don't), and overall help us improve it.

The survey will be open from 1 September to 15 October, 2010.

The results will be published at GitSurvey2010 on Git Wiki.


Nearing 1.7.2 final...

It has really been a while since I tagged the last feature release 1.7.1 in late April, just before I left my previous job.  We have a bit shy of 500 commits since 1.7.1, coming from 90 contributors in total.  These numbers are quite similar to the change between 1.7.0 and 1.7.1 (between Feb 12, 2010 and Apr 23, 2010).

Happy birthday to me ;-)

Many things happened since I wrote anything here, including moving to the silicon valley area, changing of day job, and then getting older by one year.

I have been slower than my usual self for the past several weeks or so, but I think I got over the initial hump already and hoping to be productive back again soon.

Fun with What's Cooking

As people are aware from my "Fun with..." series of articles here, I use topic branch workflow heavily.  Each patch series from other people (and myself) forks a new topic, typically from the 'master' branch, and it is first merged to the 'pu' (proposed updates) integration branch.  After a review (or more), once the patches start taking a reasonable shape, the topic is then merged to the 'next' integration branch, and eventually to the 'master' integration branch.  At any point, improvements and fixups can be added to the topic branch and the updated tip of the topic is merged to either 'pu' or 'next'.

This workflow obviously needs a good tool to keep track of how individual topics are doing, especially when you start juggling more than handful of branches.  For each topic, you would want to see these things in order to judge the done-ness of the topic:
  • what commits are on it;
  • which part of it was merged to 'next' and when;
  • how long has it been since the last update was made to it.
The format I use for this is "What's cooking" summary, an example of which can be seen here.

I have been using a hacky shell script to generate and update this list.  Its output was acceptable, but it was very slow (It took about 1.5 minutes for a typical run in my repository with 40-or-so topic branches).  I've been telling myself to rewrite it but running it and waiting for it to finish gave me a good excuse to go away from the keyboard and grab a cup of coffee, so it did not happen for a long time.

But finally I rewrote it yesterday, and it got a lot better.

The most obvious speed-up comes from the fact that the old script was doing all the computation and comparison in the shell (it had "while read ...; do ... ; done" loop reading from the output of various git commands all over the place).  The new one written in Perl eliminates all that, and also it grabs as much information as possible with a small number of calls to the underlying git commands.  For example, the script used to run "git merge-base" to see what's merged to what for many pairs of commits, but now it runs "git show-branch --sparse" on many branches  to grab the necessary information from them in one go.

Now the same job takes about 1.5 seconds to run.  This is probably a great loss to coffee growers of the island of Sumatra ;-).

1.7.1-rc0 is out

I've been meaning to make the release cycle of git a bit shorter and keep it 6 to 8 weeks, but since I tagged 1.7.0 mid-February, there were too many patches in flight to get things stabilized.  I should have declared feature freeze in mid March in order to shoot for late March release.  It slipped for 3 weeks already.

In any case, -rc0 is out, and it should be pretty close to feature complete for the 1.7.1 release.

To celebrate, I treated myself with a new LED monitor (LG E2350V).




原書はとてもていねいに書いてあって、git のバージョンが1.6.0になってからの本なので、つい最近リリースした1.7.0の時代になっても古くて使えないという感じはない良書でした。



Let it rip.

Multiple provisional and related steps can be batched.

staged, outstanding changes to be committed.

More Fun with building git on OpenBSD (or not)

As I wrote earlier, my set of VMs now include an OpenBSD (4.6) installation.  I've been seeing frequent build feature that ends with something like:
gmake[1]: write error
during the "make install" step.

After a few minutes of googling, it turns out that this has nothing to do with git or its build procedure, but many people seem to be having the exact same problem while building anything on the platform.  Answers given by OpenBSD people range from "Is your disk full?" (which is a sensible thing to ask, but the real issue seems to be that the platform makes processes misbehave when somebody turns non-blocking I/O on file descriptors, even though technical details are sketchy from my limited googling) to "Use binary packages, instead of trying to build your own" (which is surprisingly unhelpful--I have to wonder what the person who gave such an answer would do when he or she encounters the same issue).  People who asked for help seem to all end up saying "I give up---I'll re-run make when I see it happens."

It seems that running make without -j (multiple jobs, I usually run -j2 to -j4 on other platforms) and also feeding /dev/null to its standard input help the situation somewhat, but it is a bit surprising that a very basic build infrastructure is left unreliable like this on a popular platform.  Also having to run the test suite without parallelization is a major pain.

My FreeBSD 8.0 installation does not seem to share this issue, luckily.