Wednesday, December 28, 2011
Git 1.7.8.2
The latest maintenance release Git 1.7.8.2 is available.
Again, please note that this is not a release with new features (upcoming 1.7.9 is expected to be released late January next year to include the pulling of signed tags and other goodies).
Please upgrade to get the accumulated bugfixes since 1.7.8.1
Enjoy!
Tuesday, December 27, 2011
Hopefully the last push-out of the year
By now I know a bit better than taking the lack of serious regression reports during the holiday weekend as a sign of perfection of the upcoming release, but I will tag 1.7.9-rc0 soonish anyway. As far as I can see, the tip of 'master' branch is now feature complete for 1.7.9, modulo possible bugs and regressions, of course.
We've done quite a lot during this short cycle leading to 1.7.9 and hopefully we can use the next few weeks squashing any regressions, preparing for a solid release by the end of January 2012 (Knock wood...).
A big Thank-you for all the contributors and testers.
We've done quite a lot during this short cycle leading to 1.7.9 and hopefully we can use the next few weeks squashing any regressions, preparing for a solid release by the end of January 2012 (Knock wood...).
A big Thank-you for all the contributors and testers.
Wednesday, December 21, 2011
Git 1.7.8.1
The latest maintenance release Git 1.7.8.1 is available. Note that this
is not a release with new features (upcoming 1.7.9 is expected to be
released late January next year to include the pulling of signed tags and
other goodies).
Please upgrade to get the accumulated bugfixes since 1.7.8 release from:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
198e23e6e50245331590a6159ccdbdbe1792422c git-1.7.8.1.tar.gz
8f674dba39d9ae78928abfe9d924b0855e283e98 git-htmldocs-1.7.8.1.tar.gz
b49ce0b4da4f85671693c9b2c6f6a8b8ee65c809 git-manpages-1.7.8.1.tar.gz
is not a release with new features (upcoming 1.7.9 is expected to be
released late January next year to include the pulling of signed tags and
other goodies).
Please upgrade to get the accumulated bugfixes since 1.7.8 release from:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
198e23e6e50245331590a6159ccdbdbe1792422c git-1.7.8.1.tar.gz
8f674dba39d9ae78928abfe9d924b0855e283e98 git-htmldocs-1.7.8.1.tar.gz
b49ce0b4da4f85671693c9b2c6f6a8b8ee65c809 git-manpages-1.7.8.1.tar.gz
- In some codepaths (notably, checkout and merge), the ignore patterns recorded in $GIT_DIR/info/exclude were not honored. They now are.
- "git apply --check" did not error out when given an empty input without any patch.
- "git archive" mistakenly allowed remote clients to ask for commits that are not at the tip of any ref.
- "git checkout" and "git merge" treated in-tree .gitignore and exclude file in $GIT_DIR/info/ directory inconsistently when deciding which untracked files are ignored and expendable.
- LF-to-CRLF streaming filter used when checking out a large-ish blob fell into an infinite loop with a rare input.
- The function header pattern for files with "diff=cpp" attribute did not consider "type *funcname(type param1,..." as the beginning of a function.
- The error message from "git diff" and "git status" when they fail to inspect changes in submodules did not report which submodule they had trouble with.
- After fetching from a remote that has very long refname, the reporting output could have corrupted by overrunning a static buffer.
- "git pack-objects" avoids creating cyclic dependencies among deltas when seeing a broken packfile that records the same object in both the deflated form and as a delta.
Tuesday, December 20, 2011
"Pulling signed tag" is already in use in the field
[update: with finishing touches, this will be part of 1.7.9 release]
One of the more important features we wanted to have for the next release of Git (1.7.9) is to support a workflow where a pull request for a signed tag is sent to the integrator and git pull in response to the request automatically verifies the GPG signature embedded in the signed tag. See this for the background.
Earlier, a typical pull request was for a branch name in the publishing repository of a contributor, and worse yet, the default request message created by the git request-pull command did not even mention what commit to expect as the result of a requested pull, which meant that it was unnecessarily hard to make sure what was pulled was genuinely what the contributor had produced for the integrator and for third-party auditors.
This feature has been cooking in the next branch of the Git project for a while, and recently graduated to the master branch to become part of the upcoming release. Linus has been using the in-development verison, and I learned that he made a commit (2240a7b (Merge tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4, 2011-12-14)) that pulls a signed tag in response to a pull request from Ted several days ago already!
It always is satisfying to see that the result of our hard work is used in the field.
The workflow between the contributor (or a lieutenant) and the integrator looks like this:
(contributor)
After preparing the work to be pulled, use "git tag -s" to create a signed tag.
$ git checkout work
$ ... "git pull" from sublieutenants, "git commit" your own work ...
$ git tag -s -m "Completed frotz feature" frotz-for-linus work
And push the tag out to your publishing repository. You do not have to push your work branch or anything else.
$ R=example.com:/git/froboz.git/
$ git push $R frotz-for-linus
Then prepare a pull request message.
$ git request-pull v3.2 $R frotz-for-linus >msg.txt
The arguments are
The following changes since commit 703f05ad5835cff92b12c29aecf8d724c8c847e2:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git/ frotz-for-linus
for you to fetch changes up to 406da7803217998ff6bf5dc69c55b1613556c2f4:
Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
----------------------------------------------------------------
Completed frotz feature
----------------------------------------------------------------
A U Thor (7):
frotz: do not use --index in the short usage output
frotz: Add tests and documentation for frotz
...
The signed tag message is shown prominently between the dashed lines before the short-log, so you may want to justify why pulling your work is worthwhile when creating the signed tag.
Then open your favorite mailer, read msg.txt in, edit and send it to your integrator.
(integrator)
After seeing such a pull request message, fetch and integrate the tag named in the request.
$ git pull example.com:/git/froboz.git/ frotz-for-linus
It will always open an editor to allow the integrator to fine tune the commit log message for the merge when merging a signed tag. In the editor, the integrator will see something like this:
Merge tag 'frotz-for-linus' of example.com:/git/froboz.git/
Completed frotz feature
# gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
# gpg: Good signature from "A U Thor <author@example.com>"
provided if the signature in the signed tag verifies correctly. As usual, the lines commented with # are stripped out. The resulting commit records the contents of the signed tag in a hidden field so that it can be used by others to audit in the future, so the integrator does not have to keep a separate copy of the tag in his repository (i.e. "git tag -l" won't list frotz-for-linus tag in the above example).
After the integrator responds to the pull request and the work becomes part of the permanent history, the contributor can remove the tag from the publishing repository if he or she chooses to in order to keep the tag namespace clean.
(contributor)
$ git push example.com :refs/tags/frotz-for-linus
One of the more important features we wanted to have for the next release of Git (1.7.9) is to support a workflow where a pull request for a signed tag is sent to the integrator and git pull in response to the request automatically verifies the GPG signature embedded in the signed tag. See this for the background.
Earlier, a typical pull request was for a branch name in the publishing repository of a contributor, and worse yet, the default request message created by the git request-pull command did not even mention what commit to expect as the result of a requested pull, which meant that it was unnecessarily hard to make sure what was pulled was genuinely what the contributor had produced for the integrator and for third-party auditors.
This feature has been cooking in the next branch of the Git project for a while, and recently graduated to the master branch to become part of the upcoming release. Linus has been using the in-development verison, and I learned that he made a commit (2240a7b (Merge tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4, 2011-12-14)) that pulls a signed tag in response to a pull request from Ted several days ago already!
It always is satisfying to see that the result of our hard work is used in the field.
The workflow between the contributor (or a lieutenant) and the integrator looks like this:
(contributor)
After preparing the work to be pulled, use "git tag -s" to create a signed tag.
$ git checkout work
$ ... "git pull" from sublieutenants, "git commit" your own work ...
$ git tag -s -m "Completed frotz feature" frotz-for-linus work
And push the tag out to your publishing repository. You do not have to push your work branch or anything else.
$ R=example.com:/git/froboz.git/
$ git push $R frotz-for-linus
Then prepare a pull request message.
$ git request-pull v3.2 $R frotz-for-linus >msg.txt
The arguments are
- the version of the integrator's commit you based your work on;
- the URL of the repository, to which you have pushed what you want to get pulled; and
- the name of the tag you want to get pulled (earlier, you could only write branch names here).
The following changes since commit 703f05ad5835cff92b12c29aecf8d724c8c847e2:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git/ frotz-for-linus
for you to fetch changes up to 406da7803217998ff6bf5dc69c55b1613556c2f4:
Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
----------------------------------------------------------------
Completed frotz feature
----------------------------------------------------------------
A U Thor (7):
frotz: do not use --index in the short usage output
frotz: Add tests and documentation for frotz
...
The signed tag message is shown prominently between the dashed lines before the short-log, so you may want to justify why pulling your work is worthwhile when creating the signed tag.
Then open your favorite mailer, read msg.txt in, edit and send it to your integrator.
(integrator)
After seeing such a pull request message, fetch and integrate the tag named in the request.
$ git pull example.com:/git/froboz.git/ frotz-for-linus
It will always open an editor to allow the integrator to fine tune the commit log message for the merge when merging a signed tag. In the editor, the integrator will see something like this:
Merge tag 'frotz-for-linus' of example.com:/git/froboz.git/
Completed frotz feature
# gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
# gpg: Good signature from "A U Thor <author@example.com>"
provided if the signature in the signed tag verifies correctly. As usual, the lines commented with # are stripped out. The resulting commit records the contents of the signed tag in a hidden field so that it can be used by others to audit in the future, so the integrator does not have to keep a separate copy of the tag in his repository (i.e. "git tag -l" won't list frotz-for-linus tag in the above example).
After the integrator responds to the pull request and the work becomes part of the permanent history, the contributor can remove the tag from the publishing repository if he or she chooses to in order to keep the tag namespace clean.
(contributor)
$ git push example.com :refs/tags/frotz-for-linus
Sunday, December 18, 2011
Moving forward to 1.7.9
A handful topics that have been cooking on the 'next' branch have now been graduated to the 'master' branch, to be included in the upcoming Git 1.7.9 release. They are all relatively minor fixes and a small feature or two, except for one, which is to stream large files directly to a packfile upon "git add", instead of storing them individually in loose object files and having to later repack them into a single pack, which would doubly be time consuming.
As I wrote earlier, we expect to make Git 1.7.9 a fairly focused release with only small number of new features around high impact themes:
Of course, there are other miscelaneous features and fixes already in the 'master' branch and also still in flight and cooking in the 'next' branch, but as far as the big changes are concerned, we are about 80% feature complete as of tonight. The credential API is expected to hit the 'master' branch in a few days.
As I wrote earlier, we expect to make Git 1.7.9 a fairly focused release with only small number of new features around high impact themes:
- Better and more auditable communication in pull based workflow by supporting electronically signed pull requests that records more meaningful branch description;
- More pleasant end-user experience by providing credential helper API to allow platform native keychain implementations to supply authentication material during "git push" and "git pull";
- i18n of messages out of the end-user facing programs;
- Better large-contents support.
Of course, there are other miscelaneous features and fixes already in the 'master' branch and also still in flight and cooking in the 'next' branch, but as far as the big changes are concerned, we are about 80% feature complete as of tonight. The credential API is expected to hit the 'master' branch in a few days.
Epson WorkForce 545
My wife wanted a new printer (as the old HP has been acting up), so gave a visit to a local office electronics shop after running a few product searches.
The printer should support Google Cloud Print (as both my wife and I carry Android phones), and also should be supported by CUPS. I ended up getting Epson WorkForce 545 which is an all-in-one wired/wireless unit, simply because HP does not have a good impression on me anymore, and because I never used Kodak printers.
After a few trial-and-error sessions, it was reasonably easy to figure out how to configure it.
I first tried to connect it via WiFi. One glitch was that there didn't seem to be any way to learn the MAC address of the unit (the WiFi router is configured to talk WPA/WPA2 but also to filter connections based on MAC). I however was happy to see that its panel display offered to print diagnostic after it failed to connect and there was its MAC address printed there. After that, it was easy to configure it to authenticate to the WiFi router.
As the unit will sit immediately next to the router, however, I decided to disable WiFi altogether and give it a wired connection with fixed address.
After connecting to the network, interestingly, it was much easier to configure the unit to work with the Google Cloud Print than with CUPS.
A newer Windows box of my wife (I think it runs something called Windows 7) found the printer without me doing anything in particular; just being on the same network segment seemed to be enough, and then the Windows box installed the printer drivers itself.
Visiting the IP address I gave to the unit with the web browser, there were a handful of controls, and the top one was to make it work with Google Cloud Print. It just redirected the browser to google.com for OAuth and I had the printer associated with my Gmail account. From there, I can share the access to the printer with my wife's Gmail account and with my work account.
As I do not print much (and nothing at home), this was the first time I added a network printer to CUPS. After blindly trying random URLs like http://ip-address-of-unit:631, ipp://ip-address-of-unit/, etc., finally figured out that this particular model (or perhaps recent Epson in this class in general) wants to be connected with socket://ip-address-of-unit as its URL, but I did not see this documented anywhere.
An older Windows box my wife uses to control her computerized weaving loom (I think it runs Windows XP) was a different issue. It didn't see and did not want to connect to the wired printer, even though it could see my Linux box that is running samba. Adding an entry for it in /etc/samba/smb.conf was a simple task after figuring out what needs to be done (which unfortunately took too long for my liking). In the printer's section I needed to add use client driver = yes for it to work.
By the way, at the office electronics shop, I saw the new models of Kindle family (including the Fire), Nook color and the Nook tablet. Somehow Fire looked too thick and unwieldy to me, while Nook tablet looked slim and very nice. I didn't buy neither, though...
The printer should support Google Cloud Print (as both my wife and I carry Android phones), and also should be supported by CUPS. I ended up getting Epson WorkForce 545 which is an all-in-one wired/wireless unit, simply because HP does not have a good impression on me anymore, and because I never used Kodak printers.
After a few trial-and-error sessions, it was reasonably easy to figure out how to configure it.
I first tried to connect it via WiFi. One glitch was that there didn't seem to be any way to learn the MAC address of the unit (the WiFi router is configured to talk WPA/WPA2 but also to filter connections based on MAC). I however was happy to see that its panel display offered to print diagnostic after it failed to connect and there was its MAC address printed there. After that, it was easy to configure it to authenticate to the WiFi router.
As the unit will sit immediately next to the router, however, I decided to disable WiFi altogether and give it a wired connection with fixed address.
After connecting to the network, interestingly, it was much easier to configure the unit to work with the Google Cloud Print than with CUPS.
A newer Windows box of my wife (I think it runs something called Windows 7) found the printer without me doing anything in particular; just being on the same network segment seemed to be enough, and then the Windows box installed the printer drivers itself.
Visiting the IP address I gave to the unit with the web browser, there were a handful of controls, and the top one was to make it work with Google Cloud Print. It just redirected the browser to google.com for OAuth and I had the printer associated with my Gmail account. From there, I can share the access to the printer with my wife's Gmail account and with my work account.
As I do not print much (and nothing at home), this was the first time I added a network printer to CUPS. After blindly trying random URLs like http://ip-address-of-unit:631, ipp://ip-address-of-unit/, etc., finally figured out that this particular model (or perhaps recent Epson in this class in general) wants to be connected with socket://ip-address-of-unit as its URL, but I did not see this documented anywhere.
An older Windows box my wife uses to control her computerized weaving loom (I think it runs Windows XP) was a different issue. It didn't see and did not want to connect to the wired printer, even though it could see my Linux box that is running samba. Adding an entry for it in /etc/samba/smb.conf was a simple task after figuring out what needs to be done (which unfortunately took too long for my liking). In the printer's section I needed to add use client driver = yes for it to work.
By the way, at the office electronics shop, I saw the new models of Kindle family (including the Fire), Nook color and the Nook tablet. Somehow Fire looked too thick and unwieldy to me, while Nook tablet looked slim and very nice. I didn't buy neither, though...
Friday, December 9, 2011
The Disappearing Spoon: And Other True Tales of... by Sam Kean
Every once in a while, I receive gifts from satisfied Git friends, chosen from my Amazon Wish list.
And today was such a day.
I enjoy reading history of science. Thanks Miro!
Friday, December 2, 2011
Git 1.7.8
Git 1.7.8 is finally out.
The most notable improvement from my point of view is tightening of the checks on the data that go and come over the wire between repositories, but it probably is and should be invisible to the end users. Many other small improvements are all over the place.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
7453e737e008f7319a5eca24a9ef3c5fb1f13398 git-1.7.8.tar.gz
2734079e22a0a6e3e78779582be9138ffc7de6f7 git-htmldocs-1.7.8.tar.gz
93315f7f51d7f27d3e421c9b0d64afa27f3d16df git-manpages-1.7.8.tar.gz
Have fun.
The development cycle for the next release is expected to last for 8 weeks til the end of January, and some of the major planned topics are listed here.