Thursday, April 28, 2011

Keep ignoring the "package manager" discussion thread, which I am not personally interested in, and I do not want to see our core people waste their time on. I am however interested in adding some sort of plug-in that the users can pick and choose and even override the native subcommands (e.g. "git merge") in a controlled way, but the discussion seems to be going in a totally irrelevant direction.

Queued 29 patches from 9 people.Merged 6 topics to 'master' branch, to include in the next release.Merged 8 topics to 'next' branch for public testing.

Monday, April 25, 2011

Created a calendar to keep track of the progress of 1.7.6 cycle. If you happen to use Google Calendar, you can paste:

jfgbl2mrlipp4pb6ieih0qr3so@group.calendar.google.com

in the "Other calendars" box (where a gray "Add a friend's calendar" appears), but you won't be missing much even if you don't (I only have week numbers and the target tagging dates, nothing more interesting than that). The plan for 1.7.6 cycle can also be seen at Post 1.7.5 plans.

Updated the "Note from the Maintainer". Unlike the previous updates, rewrote many parts of it to shorten the document, and added the "Reporting bugs" section.

Discussed CURLOPT_POSTFIELDS gotcha with Shawn, and sent out one patch to the list for review.

Reviewed and commented on 13 topics.

After giving them another review, merged 30 topics for public testing on 'next'; the majority of the topics are what have been already cooking during the feature freeze period at the end of the previous cycle.

This message is written by the maintainer and talks about how Gitproject is managed, and how you can work with it.

Mailing list and the community

The development is primarily done on the Git mailing list. Helprequests, feature proposals, bug reports and patches should be sent tothe list address . You don't have to besubscribed to send messages. The convention on the list is to keepeverybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,I am not subscribed".

If you sent a patch and you did not hear any response from anybody forseveral days, it could be that your patch was totally uninteresting,but it also is possible that it was simply lost in the noise. Pleasedo not hesitate to send a reminder message in such a case. Messagesgetting lost in the noise is a sign that people involved don't haveenough mental/time bandwidth to process them right at the moment, andit often helps to wait until the list traffic becomes calmer beforesending such a reminder.

Reporting bugs

When you think git does not behave as you expect, please do not stop yourbug report with just "git does not work". "I tried to do X but it did notwork" is not much better, neither is "I tried to do X and git did Y, whichis broken". It often is that what you expect is _not_ what other peopleexpect, and chances are that what you expect is very different from whatpeople who have worked on git have expected (otherwise, the behaviorwould have been changed to match that expectation long time ago).

Please remember to always state

what you wanted to do;

what you did (the version of git and the command sequence to reproducethe behavior);

what you saw happen;

what you expected to see; and

how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for furtherhints.

Repositories, branches and documentation.

My public git.git repository is at:

git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, Ialso push into an alternate here:

git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one (there are afew other mirrors I push into at sourceforge and github as well).

The above URL is the top-level documentation page, and it has links todocumentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,but is mostly used to keep some helper scripts I use to maintain git.For example, the script to maintain the two documentation branches arefound there as dodoc.sh, which may be a good demonstration of how touse a post-update hook to automate a task after pushing into arepository.

There are four branches in git.git repository that track the source treeof git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested andready to be used in a production setting. Every now and then, a "featurerelease" is cut from the tip of this branch and they typically are namedwith three dotted decimal digits. The last such release was 1.7.5 done onApr 24, 2011. You can expect that the tip of the "master" branch isalways more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from"master" at that point. Obvious, safe and urgent fixes after a featurerelease are applied to this branch and maintenance releases are cut fromit. The maintenance releases are named with four dotted decimal, namedafter the feature release they are updates to; the last such release was1.7.4.5. New features never go to this branch. This branch is alsomerged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send aseries of patches, after review on the mailing list, a separate topicbranch is forked from the tip of "master" and your patches are queuedthere, and kept out of "master" while people test it out. The quality oftopic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. Ingeneral, the "next" branch always contains the tip of "master". It mightnot be quite rock-solid production ready, but is expected to work more orless without major breakage. The "next" branch is where new and excitingthings take place. A topic that is in "next" is expected to be polished toperfection before it is merged to "master" (that's why "master" can beexpected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topicbranches. The topics on the branch are not complete, well tested, nor welldocumented and need further work. When a topic that was in "pu" proves tobe in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics arecurrently in flight. Sometimes, an idea that looked promising turns outto be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"usually will not be either. After a feature release is made from"master", however, "next" will be rebuilt from the tip of "master"using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the nextrelease, nor even in any future release. There were cases that topicsneeded reverting a few commits in them before graduating to "master", or atopic that already was in "next" was reverted from "next" because fatalflaws were found in it after it was merged.

Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changesshould be sent. As described in contrib/README, I would delegate fixesand enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have theirown authoritative repository and maintainers:

git-gui/ comes from git-gui project, maintained by Pat Thoyts:

git://repo.or.cz/git-gui.git

gitk-git/ comes from Paul Mackerras's gitk project:

git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the currentshape. Especially I would like to thank the git list regulars whose helpI have relied on and expect to continue relying on heavily:

Sunday, April 24, 2011

The cycle took a bit longer than I would have liked (83 days), but finally I tagged the latest release v1.7.5 with 547 changes from 77 contributors. The previous release v1.7.4 had 554 changes from 104 contributors and it took 134 days.

Changes are very well balanced: 20% in implementation, 20% in tests, 15% in documentation. There is nothing particularly earth-shattering but the foundation for i18n is now laid out which is internally a big thing. We also had a large update to git-gui's po files (pt_br).

On the development branch a handful of interesting and rule changing features have already been cooking. Hopefully the next cycle will be even shorter.