Git Blame

Git 1.8.3-rc2

2013-05-13T17:58:00.002-07:00

The second and planned-to-be-the-final release candidate for the upcoming 1.8.3 release was tagged today. Also, the release tarballs at kernel.org are back ;-)

Hopefully we can have the final late next week, but we might end up doing another release candidate. Please help testing the rc2 early to make sure you can have a solid release.

There are numerous little fixes, new features and enhancements that cannot be covered in a single article, so I'll only highlight some selected big-picture changes here. For the full list of changes, please refer to the draft Release Notes.

Preparation for 2.0

A lot of work went into preparing the users for 2.0 release that will come sometime next year, which promises large backward-incompatible UI changes:

"git push" that does not say what to push from the command line will not use the "matching" semantics in Git 2.0 (it will use "simple", which pushes your current branch to the branch of the same name only when you have forked from it previously; e.g. "git push origin" done while you are on your "topic" branch that was previously created with "git checkout -t -b topic origin/topic" will push your "topic" branch to origin).

This default change will hurt old-timers who are used to the traditional "matching" (if you have branches A, B and C, and of the other side has branches A and C, then your branches A and C will update their branches A and C, respectively), and they can use "push.default" configuration variable to keep the traditional behaviour. I.e.

$ git config push.default matching

Recent releases since 1.8.0 has been issuing warnings when you do not have any push.default configuration set, and this release continues to do so.
"git add -u" and "git add -A" that is run inside a subdirectory without any other argument to specify what to add will operate on the entire working tree in Git 2.0, so that the behaviour will be more consistent with "git commit -a" (e.g. "edit file && cd subdir && git commit -a" will commit the change to the file you just edited which is outside the directory you ran "git commit" in).

Users can say "git add -u ." and "git add -A ." (the "dot" means "the current directory") to limit the operation to the subdirectory the command is run in with the traditional versions of Git (and this will stay the same in Git 2.0 or later), so there will be no configuration variable to change the default.

The 1.8.3 and later releases do not yet change the behaviour until Git 2.0, and limit these operations to the current subdirectory, but they do notice when you have changes outside your current subdirectory and warn, saying that if you were to type the same command to Git 2.0, you would be adding those other files to your index, and encourages you to learn to add that explicit "dot" if you mean to add changed or all files in the current subdirectory only.
"git add path" has traditionally been a no-op for removed files (e.g. "rm -f dir/file && git add dir" does not record the removal of dir/file to the index), but Git 2.0 will notice and record removals, too.

The 1.8.3 and later releases do not yet change the behaviour until Git 2.0, but they do notice when you have removed files that match the path and warn, saying that if you were to type the same command to Git 2.0, you would be recording their removal, and encourages you to learn to use the --ignore-removal option if you mean to only add modified or new files to the index.

Tightening of command line verification

There are quite a many UI fixes that tie loose ends. Some commands assumed that the users were perfect and would never throw nonsense command line arguments at them, and some operations that need two parameters were happily carried out even when they got three parameters without diagnosing such a command line as an error (the excess one was simply ignored).

Many of them have been updated to detect and die on such errors.

Helping our friends at Emacs land

We expedited the update of the foreign SCM interface to bzr we have in the contrib/ area since 1.8.2, and included a version that is vastly modified from what we had before, with help from some Emacs folks. This code could be a bit rougher than the rest of Git that usually moves slowly and cautiously, but we decided that, given the circumstance, it is more important to push out some improved version early, in order to help our friends in Emacs land, who have been (reportedly) suffering from less than ideal response to the issues they are having with their SCM of choice.

A beginning of a better triangular workflow support

The recommended workflows to collaborate with others are either:

to have your own repository and push your work there while pulling from your upstream to keep up to date, or
to have a central repository where everybody pushes to and pulls from.

The latter was primarily to make those who are coming from centralized version control systems feel at ease, and the repository configuration mechanisms such as "remote.origin.url" variable were designed to help that workflow (there is one "origin" you pull from and push to). The former however is also important, and many people on Git hosting sites (e.g. GitHub) employ this workflow (you pull from one place and push to another place, but they are not the same).

A new configuration mechanism "remote.pushdefault" has been introduced to support such a triangular workflow. After you clone from somebody else's project, that upstream repository will still be your 'origin', but you can add the repository you regularly push to in order to publish your work (and presumably then you will throw a "pull request" at the upstream) as another remote, and set it to this configuration variable. E.g.

$ git clone git://example.com/frotz.git frotz
$ cd frotz
$ git remote add publish ssh://myhost.com/myfrotz.git
$ git config remote.pushdefault publish

After this, you can say "git push" and the push does not attempt to push to your origin (i.e. git://example.com/frotz.git) but to your publish remote (i.e. ssh://myhost.com/myfrotz.git) because of the last configuration.

Where do evil merges come from?

2013-04-02T11:40:00.005-07:00

A canonical example of where "evil merge" happens in real life (and is a good thing) is to adjust for semantic conflicts. It almost never have anything to do with textual conflicts.

Imagine you and your friend start with the same codebase where a function f() takes no parameter, and has two existing call-sites.

You decide to update the function to take a parameter, and adjust both existing call-sites to pass one argument to the function. Your friend in the meantime added a new call-site that calls f() still without an argument. Then you merge.

It is very likely that you won't see any textual conflict. Your friend added some code to block of lines you did not touch while you two were forked. However, the end result is now wrong. Your updated f() expects one parameter, while the new call-site your friend added does not pass any argument to it.

In such a case, you would fix the new call-site your friend added to pass an appropriate argument and record that as part of your merge.

Consider the line that has that new call-site you just fixed. It certainly did not exist in your version (it came from your friend'd code), but it is not exactly what your friend wrote, either (it did not pass any argument). That makes the merge an "evil merge".

With "git log -c/--cc", such a line will show with double-plus in the multi-way patch output to show that "this did not exist in either parent".

Measuring Project Activities (2)

2013-03-21T17:49:00.000-07:00

Continuing from an earlier article, let's see how you can compute some interesting stats on your own projects.

How much change did a release have?

As I said earlier, you can measure the extent of change to your codebase in two ways. A quicker and less precise way, and a more involved but more accurate way.

A quicker way is to ask git diff --numstat to count the deleted and added lines between the release tags, and add them up yourself. If you care about whole-file renames, you can add the -M option to the git diff command:

addremove2 () {

git diff --numstat "$@" | {

total=0 &&

while read add remove path

total=$(( $total + $add + $remove ))

done &&

echo "$total"

}

And with that helper, the main function we introduced in the earlier article can do this to compute the modified2 number for the entire release cycle and per each day:

handle () {

old="$1^0" new="$2^0"

...

modified2=$(addremove2 "$old" "$new")

mod2perday=$( echo 2k "$modified2" "$days" / p | dc )

}

How much real change did a release have?

Counting number of added and removed lines using git diff --numstat is straightforward, but this tends to over-count changes. For example, when adding a new caller to an existing code, you may have to move that existing code up in the same file (especially if it is a file-local static function) to make the callee come before the caller, or move it to a different, more "library-ish" file, while making its visibility from static to extern. Both of these kind of changes unfortunately appear as a bulk deletion of existing block of lines and bulk addition of the same contents elsewhere in the codebase.

In order to count the true amount of work went into the new release, you would want to exclude such changes from your statistics.

This is where git blame can help. In the most basic form, it can trace each and every line of a file in the given commit back to its origin, i.e. which commit it came from. By default, it notices when the whole file gets renamed (e.g. the file hello.c you are running the command on in the current release may have been called goodbye.c in an earlier release), and employs no other fancy tricks, but you can tell it to notice code movement within a file (e.g. moving the callee up in the file) with the -M option, or code moves across files (e.g. moving a static function from a file that an existing caller lives in to a different "library-ish" file, to make it also visible to a new caller in another file) with the -C option. You can also tell it to ignore whitespace changes with the -w option like you can with git diff. For example:

git blame -M -C -w -s v1.8.0..v1.8.1 -- fetch-pack.c

will show you which commit each and every line in the fetch-pack.c file came from; its output may begin like this:

745f7a8c fetch-pack.c 1) #include "cache.h"
^8c7a786 builtin/fetch-pack.c 2) #include "refs.h"
^8c7a786 builtin/fetch-pack.c 3) #include "pkt-line.h"

The first line is blamed to commit 745f7a8c, while the other lines are attributed to commit 8c7a786 (the leading caret ^ means it is attributed to a commit at the lower boundary of the range), which is the v1.8.0 release. Note that these old lines used to live in a different file builtin/fetch-pack.c in the older release, and would have been counted as additions if you used the approach based on git diff --numstat -M to count them, because there was no file renaming involved between these two releases.

Also notice that these lines may have been untouched since a commit that may be a lot older than v1.8.0, but we told the command to stop at v1.8.0 from the command line, so these are all attributed to that range boundary.

If you count the number of lines in the whole output from the above command, that will show the number of lines in the fetch-pack.c file at the v1.8.1 release. If you count the lines that do not begin with a caret, that counts the lines added in the new release.

added_to_file () {
old="$1" new="$2" path="$3"

git blame -M -C -w -s "$old".."$new" -- "$path" |
grep -v '^^' |
wc -l
}

This may be sufficient as a starting point, but we are not all interested in checking each and every commit between the two releases (e.g. the commit 745f7a8c in the above example is not the v1.8.1 release and the only thing we care about is that the line is new in the new release; we do not care where in the development cycle leading to the release it was added), so it is a waste of computational cycles.

Fortunately, you can tell git blame to pretend as if the commit tagged as v1.8.1 release were a direct and sole child of the commit tagged as v1.8.0 release with the -S option. First, you prepare a graft file to describe the parent-child relationship.

added_to_file () {
old="$1" new="$2" path="$3"
graft=/tmp/blame.$$.graft
cat >"$graft" <<-EOF
$new $old
$old
EOF
git blame -M -C -w -s "$old".."$new" -- "$path" |

...
}

The graft file lists each commit object and its parent. The above snippet says that the $new commit has a single parent, which is $old, and $old commit does not have any parent. This lets us lie to git blame that our history consists of only two commits, and one is a direct child of the other.

With this, we can tell how much new material was introduced to the given path in the new release, but what about the material removed from the old release? We can compute it in a similar way with a twist. You take a path in the old release, and pretend as if the old release were the direct child of the new release. We compute what we have added if we started from release v1.8.1 and development led to the contents of v1.8.0, like this:

removed_from_file () {
old="$1" new="$2" path="$3"
graft=/tmp/blame.$$.graft
cat >"$graft" <<-EOF
$old $new
$new
EOF
git blame -M -C -w -s "$new".."$old" -- "$path" |

grep -v '^^' |
wc -l
}

By tying these two helper functions with a list of paths that existed in the two releases, you can compute the amount of real changes made to reach the new release, but this article is getting a bit too long, so I'll leave it to another installment. We will use the added_to_file helper to construct added_to_commit function like this:

added_to_commit () {
old=$(git rev-parse "$1^0")
new=$(git rev-parse "$2^0")
list_paths_in_commit "$new" |
while read path
do
added_to_file "$old" "$new" "$path"
done | {
total=0
while read count
do
total=$(( $total + $count ))
done
echo $total
}
}

A bit annoyed by LinkedIn Endorsements

2013-03-18T09:06:00.001-07:00

A few times a week, I get "X endorsed your skills and expertise" e-mail messages from LinkedIn, listing people from my past and present. One of the embarrassing ones I saw the other day was an endorsement on "Linux Kernel", made by somebody who used to work as a receptionist at a small company I used to be at several years ago. She didn't know (and need to know) what technical work I did back then, I do not think she changed her career to know what technical work I do these days, and most importantly, I do not do the Kernel X-<.

And then today I got endorsement from a few Git people on "Ruby", but I know they know I do not do Ruby (not that I hate the language or its ecosystem; it is just I didn't get around to touch it).

I was told by the former receptionist that LinkedIn nags every once in a while to give endorsement to others and it is very easy to click on it, only to dismiss the nagging message, and ending up giving such irrelevant endorsements.

It is mildly annoying. Just as annoying as that big red "unread count" number I see on the right top corner of the Gmail window.

Grumpy I am.

Measuring Project Activities (1)

2013-03-14T21:55:00.001-07:00

Earlier, I showed a handful of metrics to view the level of activities in Git project, grouped by its release cycle, and promised to expllain how you can compute similar numbers for your projects.

This is the first of such posts. This post covers the very basics.

How long did a cycle last?

Each release is given a release tag. The latest I tagged for Git project was v1.8.2 and the release before that was v1.8.1. The release cycle began when I tagged v1.8.1 and ended when I tagged v1.8.2. As each commit in Git records commit timestamp and author timestamp, we can use diffrence between the commit timestamps of the two release.

We can ask git log to give us the timestamp for one commit:

git log -1 --format=%ct $commit

The --format= option lets us ask for various pieces of information, and %ct requests the committer timestamp, expressed as number of seconds since midnight of January 1, 1970 (epoch). You can use %ci for the same information but in ISO 8601 format, i.e. YYYY-MM-DD HH:MM:SS; see git log --help and look for "PRETTY FORMATS" for other possibilities.

So the part, given two commits, that computes the number of days between them, becomes something like this:

handle () {

old="$1^0" new="$2^0"

oldtime=$(git log -1 --format=%ct "$old")

newtime=$(git log -1 --format=%ct "$new")

days=$(( ($newtime - $oldtime) / (60 * 60 * 24) ))

...

}

We ask the commit timestamps for the two commits in seconds since epoch, take the difference, and divide that by number of seconds in a day.

How many commits do we have in the cycle?

This is a single-liner.
git log has a way to list commits in a specified range, and the range we want can be expressed as: "We are interested in commits that are ancestors of v1.8.2, but we are not interested in commits that are ancestors of v1.8.1" (as the latter is the set of commits that happened before v1.8.1).

In a merge-heavy project like Git, however, merge commits make up a significant part of the history. A logical change that consists of three patches may start its life as three commits on a topic branch to be tested, and later when it proves to be sound gets merged to the mainline with a merge commit, at which point the mainline gains 4 commits (the original three plus the merge commit). That means the real change is only 75% of the history in the example.

Of course, merging other people's work is an important part of the work done in the project, so you may want to count merge commits as well. The choice is up to you.

When I counted commits for Git project in the earlier article, I chose not to include merges, so the part that computes the number of commits between two given commits becomes:

handle () {

old="$1^0" new="$2^0"

...
commits=$(git log --oneline --no-merges "$old..$new" | wc -l)

...

}

Drop --no-merges if you want to count your merges. The --oneline option is to show a single line of output per commit; by counting the lines in the output from that command with wc -l, we can count the number of commits.

As we are not interested in the contents of the output (we are just counting the number of lines), we can also use git rev-list that only shows the commit object name, if you want.

commits=$(git rev-list --no-merges "$old..$new" | wc -l)

How many contributors did we have in the cycle?

You can list the names and e-mails of people who authored commits in a specified range in two ways.

Using the git log --format we saw earlier, we can ask the name %an and e-mail %ae of the author, i.e.

git log --no-merges --format="%an <%ae>" "$old..$new"

You can count the unique lines in the output from this command. That is the list of your contributors. The end result will become something like this:

authors=$(git log ...the same as above... | sort -u | wc -l)

The other way is to use the git shortlog command designed specifically for this purpose.

git shortlog --no-merges -s -e "$old..$new"

The command without -e option only shows the names (and with it, names and e-mails). It lists commits made by each author along with the author name when run without -s option (and with it, the number of commits and the author's name on the same line). So the number of lines in the output from the above command is the number of your contributors.

authors=$(git shortlog --no-merges -s -e "$old..$new" | wc -l)

Again, if you want to count merges, drop --no-merges from the command line.

How many new contributors have we added during the cycle?

This is a bit trickier than the previous one. The idea is to list contributors we already had in the entire history before v1.8.1, and subtract that from the list of contributors in the entire history up to v1.8.2. The remainder are the newcomers you want to welcome when writing your release notes.

The contributors in the entire history leading to a commit can be listed with a helper function:

authors () {
git log --no-merges --format="%an <%ae>" "$@" | sort -u
}

and we can write the entire thing using the helper function like so:

handle () {

old="$1^0" new="$2^0"

...
authors "$old" >/tmp/old
authors "$new" >/tmp/new
new_authors=$(comm -13 /tmp/old /tmp/new | wc -l)

...

}

The authors helper function will write the authors for the old history and new history into two temporary files, both in sorted order, and using comm -13, we list lines that only appear in /tmp/new to see who are the new contributors.

In the next installment of this series, let's count the changes made to the codebase by these commits we counted in this article.

So how well are we doing lately?

2013-03-13T13:30:00.000-07:00

Git v1.8.2 has 630+ non-merge commits since v1.8.1 release.

Averaged over time, the impact of each individual commit is about the same (because we reject an oversized patch that does too many unrelated things and have the submitter split it into multiple patches), so if one release cycle has twice the non-merge commits compared to another cycle, we can say it was about twice as busy.

But from time to time, it is good to measure our progress with different metrics to see how different metrics correlate with each other.

The table at the end lists how long each release cycle lasted, how many non-merge commits we had in the cycle and in each day in the cycle and how many lines of code (counting only *.[ch] source files) were affected in the cycle and in each day in the cycle. The "lines of code affected" are counted in two different ways.

We can see that the latest release cycle was relatively active, while the previous cycle that overlapped the year-end holidays was slow, both from commit count (348 vs 635) and one modification count (2921 vs 5881), but not with the other modification count (6047 vs 6355).

The "modified" number is computed with "git blame -C -C -C -w" to track line-level movements, while the "modified2" number is computed with "git diff -M" which is less accurate when the code gets refactored, and that is where the above apparent discrepancy comes from.

The v1.8.1 cycle has a lot smaller real changes (measured by "git blame") than apparent changes (measured by "git diff -M") because it created two new files by splitting two existing files. The measurement based on "git blame -C" knows to consider bulk movement of lines by such a change as a non-event, but it will show up in "git diff --stat -M" output as a large change.

 builtin/fetch-pack.c | 950 +-------------------------------------------------------------
 builtin/send-pack.c  | 333 ----------------------
 fetch-pack.c         | 951 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 send-pack.c          | 344 +++++++++++++++++++++++

So the "modified" number is a better indication of how much actual work is done, but it is painfully expensive to compute.

I'll later explain how to use blame and diff to compute these numbers for your projects in a separate post.

release	days	commits	commit/day	modified	mod/day	modified2	mod2/day
v1.5.0	90	1448	16.08	12369	137.43	13640	151.55
v1.5.1	49	643	13.12	7822	159.63	8213	167.61
v1.5.2	46	575	12.50	7604	165.30	8273	179.84
v1.5.3	104	1322	12.71	8081	77.70	9538	91.71
v1.5.4	152	1595	10.49	21422	140.93	24934	164.03
v1.5.5	66	729	11.04	9790	148.33	12172	184.42
v1.5.6	71	569	8.01	7091	99.87	8354	117.66
v1.6.0	59	731	12.38	16709	283.20	19481	330.18
v1.6.1	129	1033	8.00	10316	79.96	14262	110.55
v1.6.2	69	499	7.23	4835	70.07	5322	77.13
v1.6.3	63	692	10.98	6642	105.42	8687	137.88
v1.6.4	83	500	6.02	13571	163.50	14296	172.24
v1.6.5	72	412	5.72	5018	69.69	5623	78.09
v1.6.6	74	483	6.52	6011	81.22	6730	90.94
v1.7.0	51	569	11.15	7698	150.94	8635	169.31
v1.7.1	70	477	6.81	5830	83.28	6558	93.68
v1.7.2	88	532	6.04	5615	63.80	6380	72.50
v1.7.3	59	481	8.15	20753	351.74	21473	363.94
v1.7.4	134	746	5.56	8527	63.63	9744	72.71
v1.7.5	83	548	6.60	6766	81.51	7543	90.87
v1.7.6	63	427	6.77	3962	62.88	4351	69.06
v1.7.7	96	563	5.86	8928	93.00	10107	105.28
v1.7.8	62	426	6.87	5098	82.22	5463	88.11
v1.7.9	56	391	6.98	6338	113.17	6886	122.96
v1.7.10	69	440	6.37	5051	73.20	7271	105.37
v1.7.11	72	652	9.05	7354	102.13	8863	123.09
v1.7.12	63	382	6.06	3060	48.57	3411	54.14
v1.8.0	62	497	8.01	5611	90.50	6037	97.37
v1.8.1	71	348	4.90	2921	41.14	6047	85.16
v1.8.2	71	635	8.94	5881	82.83	6599	92.94

Git 1.8.2

2013-03-13T13:25:00.000-07:00

The latest feature release Git v1.8.2 is now available at the usual places. The release has commits from 1200+ contributors, among which ~30 are new names in this cycle (~90 people contributed 630+ changes since v1.8.1 release).

I've already mentioned backward-compatibility notes and notable new features, so I won't repeat them.

Have fun.

Git 1.8.2-rc3

2013-03-07T15:13:00.000-08:00

This is the third and planned-to-be-the-final release candidate for the upcoming 1.8.2 release. Hopefully we can have the final sometime next week.

Reviewing the draft release notes, I see that there aren't many earth-shattering new features, but there are quite a few niceties around the fringes. To name a few at random:

Command line completion (in contrib/completion) has learned what can be "git add"ed and what are irrelevant. You would not want "git add hello.<TAB>" to offer choices between hello.c and hello.h when you only have changes in hello.c and hello.h is unmodified.
The patterns used in .gitignore and .gitattributes files can have double-asterisk /**/ to match 0 or more levels of directories.
In the documentation, we consistently refer to Git the software as "Git", not "git" or "GIT" (the last one was a poor-man's attempt for imitating "Git" rendered in SMALL CAPS).
"git branch" used to accept nonsense parameters from the command line and silently ignored them (e.g. "git branch -m A B C"). Such an erroneous input is checked more carefully.
"git log" and friends can be told to use the same mailmap mechanism used by "git shortlog" to canonicalize the user names.
"git log --grep=<pattern>" first converts the log messages to i18n.logoutputencoding before matching them against the pattern.

For notable backward compatibility issues (read: there is none yet ;-), please refer to the earlier article on 1.8.2-rc2.

Living in the browser seems to be possible

2013-03-04T02:14:00.002-08:00

My primary Git work environment lives inside a GNU screen session that is running forever. In the first virtual terminal is an instance of Emacs, and it also is running forever. That is where I read e-mails and process patches. I have several virtual terminals in this screen session, and no matter where I physically am, I am connected to this screen session over SSH whenever I am working on Git.

Usually I open two or three Gnome terminals on my notebook and from these terminals go over SSH to the said screen session, but I tried Secure Shell in Chrome on Friday evening. An earlier version of this extension I tried long time ago did not support anything but password authentication, but the recent versions seem to grok private key authentication just fine. It is still rough in that there is no UI to tweak font sizes &c, but a few essentials can be tweaked from the JavaScript console (I hear some of you say "eek" already) and these tweaks survive browser or machine restart. I do not mind doing "set once and forget" configuration by hand.

Following its FAQ page, I came up with the following to let me get going:

term_.prefs_.set('background-color', 'white')
term_.prefs_.set('foreground-color', 'black')
term_.prefs_.set('font-family', 'monospace')
term_.prefs_.set('font-size', 12)
term_.prefs_.set('scrollbar-visible', false)

After opening the terminal window (make sure to set the extension to open in its own window—otherwise an innocent \C-w will close the terminal), I clicked to "Inspect Element", then went to "Console" to open the JavaScript console, and then typed the above four lines. Enter the connection parameter and I have a working and usable terminal. Happiness.

I didn't really mean to, but I ended up not opening any program other than Chrome over the weekend. It was rather a fun experience.

I do have to run a few local programs from time to time (e.g. GnuCash, Gimp, and Kid3 come to mind), and I do not think I can switch entirely to a Chromebook yet, but I should be able to survive for a few days with only Chrome.

Git 1.8.2 release candidate #2

2013-03-03T02:17:00.000-08:00

The upcoming release is taking shape and I am hoing that not many things will change until the final one. I just tagged the second release candidate 1.8.2-rc2 before going to bed.

There are a handful of behaviour change that are worth noting.

"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3 that already exists in the repository $there, if the rewritten tag you are pushing points at a commit that is a descendant of a commit that the old tag v1.2.3 points at. This was found to be error prone and starting with this release, any attempt to update an existing ref under refs/tags/ hierarchy will fail, without "--force".
When "git add -u" and "git add -A", that does not specify what paths to add on the command line, is run from inside a subdirectory, the scope of the operation has always been limited to the subdirectory. Many users found this counter-intuitive, given that "git commit -a" and other commands operate on the entire tree regardless of where you are. In this release, these commands give warning in such a case and encourage the user to say "git add -u/-A ." instead when restricting the scope to the current directory.
At Git 2.0 (not *this* one), we plan to change these commands without pathspec to operate on the entire tree. Forming a habit to type "." when you mean to limit the command to the current working directory will protect you against the planned future change, and that is the whole point of the new message (there will be no configuration variable to squelch this warning---it goes against the "habit forming" objective).

For exciting new features, please refer to the draft release notes.

UnFun with signed tags

2013-02-25T16:30:00.001-08:00

I sometimes wish if we can revoke signature made (with PGP/GPG) to a specific tag.

I know that an electronic signature (like a handwritten one) is to protect both parties, the one who signs, and the one who gets something signed, and allowing a signer to retroactively cancel a signature invalidates the protection given to the latter. I'd be protected from a bogus claim that I made a promise I didn't make when somebody produces a document with a signature that does not match mine, and I'd be protected from somebody who changes his mind later after signing a document to promise me with his signature.

But in the context of signing a release tag for an open source project, non-repudiation is not an issue.

I often merge the last set of topics to the 'master' (or 'maint') branch, add a signed release tag to the tip, merge the result to 'next' and higher integration branches, only to find that a few more tweaks are necessary before the real release while testing the integration branches. Since I do not push out any branch before all the main integration branches (i.e. 'maint', 'master', 'next' and 'pu') are ready, it will not hurt anybody for me to rewind 'next' and 'pu' locally, discard the tag and redo the 'master' (or 'maint') branch. I also do not push out the signed tag until all these branches are ready, so in practice I just can discard the previous signed tag (that hasn't been pushed out) and tag the tip of 'master' with the same name. Nobody will notice.

So in practice, I do not need a feature to cancel a signed tag I created earlier, but at the philosophical level. But it somewhat feels awkward.

More leftover bits

2013-02-24T22:41:00.000-08:00

I've spent the past few days to see if there were discussions that are worth salvaging but somehow petered out without reaching conclusion, veered into tangent, or did not even start.

I tried to be fairly thorough, but I am sure I have missed some. Note that I deliberately excluded ones that fall into the Nobody who knows what they are talking about has any idea how to approach this feature category. I also left out discussions that are fairly young, hoping that they will stay alive without me keeping track of them.

Teach "--first-parent" to "git rebase" to deal better with a history with (possibly evil) merges from side branches.
Cf. $gmane/198516
More fixes to bring sanity to "git diff --no-index", some discussed in the thread are definitely worthwhile, while some others are not.
Cf. $gmane/200769
The name sanitization code may be overly conservative.
Cf. $gmane/200823
The behaviour of "git filter-branch" around annotated tag may be under-documented to cause misunderstanding on the user's part, or it could be simply buggy.
Cf. $gmane/212353
Annotating a pair of commit objects and trigger interesting behaviour when they both appear in the history.
Cf. $gmane/212570
Make it safer to export mandir, htmldir, etc. from the top-level to Documentation/ Makefile.
Cf. $gmane/216222
Allow escaping glob metacharacters in .gitattributes.
Cf. $gmane/212631
Remove contrib/ciabot/.
Cf. $gmane/212649
The return value from getenv(3) may be volatile across calls.
Cf. $gmane/212660
Support VPATH build
Cf. $gmane/212744
Build on "custom comment char" to make it "custom comment prefix string", e.g. "## ".
Cf. $gmane/213802
Serving "git archive" over smart-http.
Cf. $gmane/213243
"git fetch --deepen"?
Cf. $gmane/213180 $gmane/212950
Perhaps reword some questions from "send-email"
Cf. $gmane/213233
Improve "git remote -v" output to show where these URLs come from?
Cf. $gmane/213806
Perhaps add a robust "shell portability check" mode for test scripts?
Cf. $gmane/214709
Perhaps treat failures to write to a hook process that did not consume its input as success?
Cf. $gmane/213548
"git rm -u"?
Cf. $gmane/213993
"git submodule foreach --untracked"
Cf. $gmane/214860
Prepare to change the default behaviour when "git add -u/-A" is run without pathspec with Git 2.0
Cf. $gmane/214822
Perhaps concatenate young and small packs into one as a cheap repack?
Cf. $gmane/215288
Align the logic format-patch decides to omit S-o-b to that is used by cherry-pick and commit.
Cf. $gmane/216026
Allow installation filemode to be tweaked.
Cf. $gmane/215119
"git log --cc" without other diff format specifiers like --raw should imply "--cc -p".
Cf. $gmane/215470
Perhaps "git grep" may want to pay attention to --textconv.
Cf. $gmane/215385
Perhaps forbid "log --graph --no-walk", as --graph is about connected history while --no-walk is about discrete points?
Cf. $gmane/216083
Possible merge-recursive corner case bug?
Cf. $gmane/216117
Complete smart HTTP protocol documentation?
Cf. $gmane/216262
Perhaps include an artificial HEAD to a bundle when HEAD is not specified from the command line?
Cf. $gmane/216401

Missing the normal code review process

2013-02-19T23:43:00.000-08:00

My favorite Bonker's World cartoon points out that the code review process alone does not necessarily ensure the quality of the code.

When you are living in the open, however, you as a reviewee are restrained with an extra incentive to be more careful, lest you embarrass yourself in public with silly mistakes. The reviewers have the same extra incentive to find flaws in others patches to earn their karma points. It also helps that any bug becomes shallow because the reviewers competing to find issues in your code gives any change a large enough number of eyeballs.

It is no wonder that the open source process can produce better-quality code more easily.
Unless you are working on fixing a vulnerability that is still under embargo, that is. It is even worse if the bug is in an obscure corner of the system you do not personally use very much.

You can only confide in a few of your trusted lieutenants, who all tend to think in a way similar to yourself. This greatly increases the chances of simple and silly bugs go unnoticed. And it makes you feel uneasy and stressed. You get only one chance to get this right, or the disclosure goes out. This is especially true when you thought you have everything tagged and ready, and decided to take a nap while waiting for the embargo to expire. It suddenly occurs to you that there was a corner case you missed, and you have to scramble to redo the fix.

Now that the embargo is over and the release is out, I can relax ;-)

Git 1.8.1.4

2013-02-19T23:42:00.001-08:00

The latest maintenance release Git 1.8.1.4 is now available at the usual places.
This is primarily to tighten the host verification when imap-send is talking to your mail server via TLS/SSL. The topic that was merged to the tip of 'maint' track consists of 3 patches and is based on the 1.7.6 maintenance track. This is to make it easier for the distro folks to merge the topic to their older maintenance branches to issue hotfix binary releases if they wanted to.
This release itself also contains many small updates to the user-manual.

The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

553191fe02cfac77386d5bb01df0a79eb7f163c8 git-1.8.1.4.tar.gz
bb71df6bc1fdb55b45c59af83102e901d484ef53 git-htmldocs-1.8.1.4.tar.gz
98c41b38d02f09e1fcde335834694616d0a615f7 git-manpages-1.8.1.4.tar.gz

Also the following public repositories all have a copy of the v1.8.1.4 tag and the maint branch that the tag points at:

url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git

Thanks, and enjoy.

The Maintainer's Life (1)

2013-02-18T22:44:00.001-08:00

While I was getting interviewed for an article in the "Open Source community leaders" series on a Japanese trade publication (due to come out in many weeks), I was asked an interesting question:

What is your role in the community? What is your job?

My immediate reaction was "Huh?". The interviewer contacted me knowing that I am the Git maintainer. Don't all maintainers do more or less the same thing and operate more or less in the same way?

But here is my version of what I do, anyway. What I do fall into two categories.

One is what I do as a member of the Git development community like everybody else.

Triage end-user bug-reports into non-bugs and real bugs. Non-bugs may result in referring the user to an appropriate manual page, or may result in updates to the documentation. Bugs may result in fixes.
Read other end-user requests, ranging from "Help, I do not know what I am doing" to a solidly written feature requests. Again, many may result in referring the user to an existing documentation, some may result in real enhancements.
Design and propose fixes and/or enhancements (possibly inspired by end-user inputs above, or perhaps scratching own itch) to the community and discuss with the members to reach consensus. Post a series of patches to implement the design and get them reviewed by community members. With their help, polish the patches to perfection.
Participate in the discussion and the review process initiated by other community members who do the above.

The other is what I the maintainer alone does as the project leader.

Keep an eye on end-user reports and requests that haven't been responded, find somebody in the community (i.e. victims) who are knowledgeable enough to handle them, and redirect.
Accept the patches polished in the review process and manage releases.

An interesting thing to notice is that the latter, at least when expressed as a list of bullet items, is a lot smaller than the former. Strictly speaking, the "Keep an eye on leftover bits and redirect" item could be done by anybody in the community, and in fact we saw various people acting as capable project secretaries to do exactly that from time to time. Even though I rarely do a "grand redesign with a road-map toward the future", such a topic would not be done by me as the maintainer descending from above with an edict, but as a proposal by me as one of the members of the community (bullet 3 in the former list). Also, compared to less experienced community members, I find myself saying "Let's step back a bit" a lot more often, asking other participants in design discussions to temporarily free their thinking of whatever narrow problem description originally given by the proposer of the topic, and instead to view the issue with wider context in mind. That is not done as the maintainer, but as one of the more experienced members of the development community. Other experienced community members can and often do the same to inject sanity to ongoing discussions.

I think one of the biggest reasons why the community does not come to a screeching halt when I disappear for a few weeks is because there aren't many tasks only the maintainer is supposed to do in our community in the first place. Capable others can take over fairly smoothly while I am away, because no matter who the interim maintainer is, what other community members do do not change very much.

Perhaps what the maintainer does may be different from communities to communities. How does your community work?

Git: Version Control for Everyone

2013-02-10T22:39:00.001-08:00

Received a sample copy of a new Git book from Packt publishing.

It says "Beginner's Guide" on the cover; its target audience is "everyone", which apparently means those of us who have not yet read existing Git books by Swicegood, Loeliger, or Chacon, or find them a bit intimidating.

This book turned out to be a very interesting read.

It is relatively short (160 pages), and can be browsed in pretty much a single sitting. I found its approach to introduce Git to "everybody" readers very interesting. After showing step-by-step installation on major platforms (which every Git book unfortunately needs to do), the document it tracks in its first Git repository as its example is "content.docx" (surprise!).

I do not recall seeing anybody start teaching Git (or any other SCM for that matter) by tracking something you cannot get a meaningful diff out of its history you can manipulate. But we coders have to admit that that is one of the definitions of "everybody"; normal people do not read diffs and apply patches.

And the book demonstrates that tracking "content.docx" is sufficient to teach many parts of Git, and successfully teaches resetting to an earlier point to discard recent history, setting up a central repository and using it to work with others by communicating, reviewing the history with gitk, git log, git shortlog, etc., without ever mentioning diffs or merges. It is only at page 107 we see text files added to the history and merge conflicts getting resolved. We do not even see git blame mentioned anywhere in the book.

If somebody tried those other "for programmers" Git books and found their introductory parts a little over his head, this book may be a good introductory book to help him get over that very initial hump.

I have never heard of the author of this book, nor any of the people listed as reviewers, on the Git mailing list or elsewhere. I find that fact alone satisfying—to see that a Git book is written by somebody who is not an insider, and the book is targeted for "everybody". It shows how much progress we, the Git development community, have made to make the system more accessible and how much Git has become to matter in the real world. Thank you, everybody in the Git community, for working on making Git a better system every day. Your work is very much appreciated.

Git 1.8.1.3

2013-02-07T16:20:00.004-08:00

Another release to give fixes for a handful bugs to users who are stuck with the maintenance track ;-) This maintenance release contains the following fixes, and other fixes to the documentation.

The attribute mechanism didn't allow limiting attributes to be applied to only a single directory itself with "path/" like the exclude mechanism does. The fix for this in 1.8.1.2 had performance degradation.
Command line completion code was inadvertently made incompatible with older versions of bash by using a newer array notation.
Scripts to test bash completion was inherently flaky as it was affected by whatever random things the user may have on $PATH.
A fix was added to the build procedure to work around buggy versions of ccache broke the auto-generation of dependencies, which unfortunately is still relevant because some people use ancient distros.
We used to stuff "user@" and then append what we read from /etc/mailname to come up with a default e-mail ident, but a bug lost the "user@" part.
"git am" did not parse datestamp correctly from Hg generated patch, when it is run in a locale outside C (or en).
Attempt to "branch --edit-description" an existing branch, while being on a detached HEAD, errored out.
"git cherry-pick" did not replay a root commit to an unborn branch.
We forgot to close the file descriptor reading from "gpg" output, killing "git log --show-signature" on a long history.
"git rebase --preserve-merges" lost empty merges in recent versions of Git.
Rebasing the history of superproject with change in the submodule has been broken since v1.7.12.
A failure to push due to non-ff while on an unborn branch dereferenced a NULL pointer when showing an error message.

For those of you who may not be familiar with how Git development works, these fixes were developed and reviewed on our mailing list (git@vger.kernel.org), and were first applied to the next branch of the main repository where developers and testers regularly pull from. They build and use the version from this branch daily to help ensuring the stability and correctness of the changes.

These changes proved to be safe after a few weeks testing period. And then they were merged to the master branch to become a part of upcoming release (1.8.2, scheduled to happen sometime in February).

Thanks to this fairly conservative development process, you can generally expect that the tip of our master branch is more stable than any released version of Git.

There are, however, people who want to avoid disruptive changes by staying behind, and to satisfy these people, among the changes that have been applied to the master branch, only the ones that are bugfixes (not feature enhancements) are merged from time to time to the maint branch and the results are tagged as maintenance releases.

This 1.8.1.3 is such a release.

Git 1.8.1.2

2013-01-28T16:39:00.003-08:00

Another release to give fixes for a handful bugs to users who are stuck with the maintenance track ;-) This maintenance release contains the following fixes, and other fixes to the documentation.

An element on GIT_CEILING_DIRECTORIES list that does not name the real path to a directory (i.e. a symbolic link) could have caused the GIT_DIR discovery logic to escape the ceiling.
Command line completion for "tcsh" emitted an unwanted space after completing a single directory name.
Command line completion leaked an unnecessary error message while looking for possible matches with paths in .
"git archive" did not record uncompressed size in the header when streaming a zip archive, which confused some implementations of unzip.
When users spelled "cc:" in lowercase in the fake "header" in the trailer part, "git send-email" failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way.

Thanks to this fairly conservative development process, you can generally expect that the tip of our master branch is more stable than any released version of Git.

This 1.8.1.2 is such a release.

Git 1.8.1.1

2013-01-14T12:05:00.000-08:00

The latest maintenance release Git 1.8.1.1 is available from the usual places. This contains many bugfixes that have been cooking on the 'master' branch since 1.8.1 was released, contributions from 27 contributors totalling 71 changes.

Git 1.8.1

2012-12-31T16:22:00.003-08:00

The latest release has just been tagged. Thanks, everybody, and a happy new year.

Git v1.8.1 Release Notes
========================

Backward compatibility notes
----------------------------

In the next major release (not *this* one), we will change the
behavior of the "git push" command.

When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there).  We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch.  There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.

"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future.  "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.


Updates since v1.8.0
--------------------

UI, Workflows & Features

 * Command-line completion scripts for tcsh and zsh have been added.

 * "git-prompt" scriptlet (in contrib/completion) can be told to paint
   pieces of the hints in the prompt string in colors.

 * Some documentation pages that used to ship only in the plain text
   format are now formatted in HTML as well.

 * We used to have a workaround for a bug in ancient "less" that
   causes it to exit without any output when the terminal is resized.
   The bug has been fixed in "less" version 406 (June 2007), and the
   workaround has been removed in this release.

 * When "git checkout" checks out a branch, it tells the user how far
   behind (or ahead) the new branch is relative to the remote tracking
   branch it builds upon.  The message now also advises how to sync
   them up by pushing or pulling.  This can be disabled with the
   advice.statusHints configuration variable.

 * "git config --get" used to diagnose presence of multiple
   definitions of the same variable in the same configuration file as
   an error, but it now applies the "last one wins" rule used by the
   internal configuration logic.  Strictly speaking, this may be an
   API regression but it is expected that nobody will notice it in
   practice.

 * A new configuration variable "diff.context" can be used to
   give the default number of context lines in the patch output, to
   override the hardcoded default of 3 lines.

 * "git format-patch" learned the "--notes=" option to give
   notes for the commit after the three-dash lines in its output.

 * "git log -p -S" now looks for the  after applying
   the textconv filter (if defined); earlier it inspected the contents
   of the blobs without filtering.

 * "git log --grep=" learned to honor the "grep.patterntype"
   configuration set to "perl".

 * "git replace -d " now interprets  as an extended
   SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
   object name.

 * "git rm $submodule" used to punt on removing a submodule working
   tree to avoid losing the repository embedded in it.  Because
   recent git uses a mechanism to separate the submodule repository
   from the submodule working tree, "git rm" learned to detect this
   case and removes the submodule working tree when it is safe to do so.

 * "git send-email" used to prompt for the sender address, even when
   the committer identity is well specified (e.g. via user.name and
   user.email configuration variables).  The command no longer gives
   this prompt when not necessary.

 * "git send-email" did not allow non-address garbage strings to
   appear after addresses on Cc: lines in the patch files (and when
   told to pick them up to find more recipients), e.g.

     Cc: Stable Kernel  # for v3.2 and up

   The command now strips " # for v3.2 and up" part before adding the
   remainder of this line to the list of recipients.

 * "git submodule add" learned to add a new submodule at the same
   path as the path where an unrelated submodule was bound to in an
   existing revision via the "--name" option.

 * "git submodule sync" learned the "--recursive" option.

 * "diff.submodule" configuration variable can be used to give custom
   default value to the "git diff --submodule" option.

 * "git symbolic-ref" learned the "-d $symref" option to delete the
   named symbolic ref, which is more intuitive way to spell it than
   "update-ref -d --no-deref $symref".


Foreign Interface

 * "git cvsimport" can be told to record timezones (other than GMT)
   per-author via its author info file.

 * The remote helper interface to interact with subversion
   repositories (one of the GSoC 2012 projects) has been merged.

 * A new remote-helper interface for Mercurial has been added to
   contrib/remote-helpers.

 * The documentation for git(1) was pointing at a page at an external
   site for the list of authors that no longer existed.  The link has
   been updated to point at an alternative site.


Performance, Internal Implementation, etc.

 * Compilation on Cygwin with newer header files are supported now.

 * A couple of low-level implementation updates on MinGW.

 * The logic to generate the initial advertisement from "upload-pack"
   (i.e. what is invoked by "git fetch" on the other side of the
   connection) to list what refs are available in the repository has
   been optimized.

 * The logic to find set of attributes that match a given path has
   been optimized.

 * Use preloadindex in "git diff-index" and "git update-index", which
   has a nice speedup on systems with slow stat calls (and even on
   Linux).


Also contains minor documentation updates and code clean-ups.


Fixes since v1.8.0
------------------

Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).

 * The configuration parser had an unnecessary hardcoded limit on
   variable names that was not checked consistently.

 * The "say" function in the test scaffolding incorrectly allowed
   "echo" to interpret "\a" as if it were a C-string asking for a
   BEL output.

 * "git mergetool" feeds /dev/null as a common ancestor when dealing
   with an add/add conflict, but p4merge backend cannot handle
   it. Work it around by passing a temporary empty file.

 * "git log -F -E --grep=''" failed to use the given 
   pattern as extended regular expression, and instead looked for the
   string literally.

 * "git grep -e pattern " asked the attribute system to read
   ":.gitattributes" file in the working tree, which was
   nonsense.

 * A symbolic ref refs/heads/SYM was not correctly removed with "git
   branch -d SYM"; the command removed the ref pointed by SYM
   instead.

 * Update "remote tracking branch" in the documentation to
   "remote-tracking branch".

 * "git pull --rebase" run while the HEAD is detached tried to find
   the upstream branch of the detached HEAD (which by definition
   does not exist) and emitted unnecessary error messages.

 * The refs/replace hierarchy was not mentioned in the
   repository-layout docs.

 * Various rfc2047 quoting issues around a non-ASCII name on the
   From: line in the output from format-patch have been corrected.

 * Sometimes curl_multi_timeout() function suggested a wrong timeout
   value when there is no file descriptor to wait on and the http
   transport ended up sleeping for minutes in select(2) system call.
   A workaround has been added for this.

 * For a fetch refspec (or the result of applying wildcard on one),
   we always want the RHS to map to something inside "refs/"
   hierarchy, but the logic to check it was not exactly right.
   (merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).

 * "git diff -G" did not honor textconv filter when looking
   for changes.

 * Some HTTP servers ask for auth only during the actual packing phase
   (not in ls-remote phase); this is not really a recommended
   configuration, but the clients used to fail to authenticate with
   such servers.
   (merge 2e736fd jk/maint-http-half-auth-fetch later to maint).

 * "git p4" used to try expanding malformed "$keyword$" that spans
   across multiple lines.

 * Syntax highlighting in "gitweb" was not quite working.

 * RSS feed from "gitweb" had a xss hole in its title output.

 * "git config --path $key" segfaulted on "[section] key" (a boolean
   "true" spelled without "=", not "[section] key = true").

 * "git checkout -b foo" while on an unborn branch did not say
   "Switched to a new branch 'foo'" like other cases.

 * Various codepaths have workaround for a common misconfiguration to
   spell "UTF-8" as "utf8", but it was not used uniformly.  Most
   notably, mailinfo (which is used by "git am") lacked this support.

 * We failed to mention a file without any content change but whose
   permission bit was modified, or (worse yet) a new file without any
   content in the "git diff --stat" output.

 * When "--stat-count" hides a diffstat for binary contents, the total
   number of added and removed lines at the bottom was computed
   incorrectly.

 * When "--stat-count" hides a diffstat for unmerged paths, the total
   number of affected files at the bottom of the "diff --stat" output
   was computed incorrectly.

 * "diff --shortstat" miscounted the total number of affected files
   when there were unmerged paths.

 * "update-ref -d --deref SYM" to delete a ref through a symbolic ref
   that points to it did not remove it correctly.

Is there any science in Amazon pricing?

2012-12-30T13:18:00.000-08:00

I keep a handful of stuff in the "Saved for later" category in my Amazon shopping cart. It is amusing to see that prices of some items constantly keep changing.

Take these earbuds, for example. I listen to podcasts while commuting with a pair of earbuds plugged to my phone, and for that purpose audiophile-grade fidelity is not a requirement. Ones from different brands I tried over time, including these, have developed frayed wire just outside the connector plug and died after several months' use. Cheap earbuds are consumables to me, and I keep a couple of unopened spares around, and restock every once in a while.

They used to be around $20, but among several colors, I noticed that one particular color started selling below $10 a few weeks ago. A few days ago it was at $8.26 and then this morning I saw it at $8.06. Another example I saw was that a deck of cards that lists at $45 fluctuated both upwards and downwards between around $30 to $45 within just a few weeks. I saw a similar pattern between $140-$160 for a pair of men's shoes within three weeks.

I am guessing one of the reasons why they keep changing the prices is because they want to encourage customers to come back to their shopping cart often. I however wonder how the price fluctuations are computed. Is it random-walk just to make sure that "The prices of items in your cart changed" notice appears often enough, or is there a deep science based on supply-and-demand and consumer psychology involved? Perhaps they are measuring how low they have to go before I move an item out of the "Saved for later" bin to see how bad a cheapskate I am?

I can understand why the price of this DVD that I kept in the "Saved for later" for the last three years gradually climbed before December 25th and then dropped soon after that day every year. But I do not expect there is much seasonality in demand with earbuds or deck of cards.

Git 1.8.1-rc3

2012-12-22T18:54:00.000-08:00

I was hoping that we can do the real 1.8.1 release this weekend, and have a slow week or two towards the new year, but I ended up with an extra release candidate. Hopefully this will be the last rc release before the real thing.

A good news is that this delay was not caused by any last minute show-stopper regression. Rather, it was only to improve the quality of the pre-formatted documentation pages that are produced when the release is made. Relative to the previous 1.8.1-rc2, the only changes in the source tarball are documentation updates.

I've updated the AsciiDoc toolchain that is used to produce the pre-formatted documentation pages (git-htmldocs and git-manpages) to a newer version. I was assuming that the distributions all build their own versions of documentation pages with their versions of tools, but apparently some of them cheat and package these pre-formatted pages and give them to their customers. So if you are a developers of such a distribution, you may want to double-check the documentation tarballs for this release candidate.

The final will be tagged sometime around the end of the year or early next year.

Git 1.8.0.2

2012-12-10T14:50:00.001-08:00

While we advance toward the v1.8.1 release on the 'master' front, fixes to a few bugs have been merged to the maintenance track and v1.8.0.2 has been tagged.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

1e1640794596da40f35194c29a8cc4e41c6b4f6d git-1.8.0.2.tar.gz
6b9e14c5b19b2e27605014252febd61a700012a3 git-htmldocs-1.8.0.2.tar.gz
ce0673256ce90451269a82a2464eab060adbfec6 git-manpages-1.8.0.2.tar.gz

Please upgrade.

Fixes since v1.8.0.1

Various codepaths have workaround for a common misconfiguration to spell "UTF-8" as "utf8", but it was not used uniformly. Most notably, mailinfo (which is used by "git am") lacked this support.
We failed to mention a file without any content change but whose permission bit was modified, or (worse yet) a new file without any content in the "git diff --stat" output.
When "--stat-count" hides a diffstat for binary contents, the total number of added and removed lines at the bottom was computed incorrectly.
When "--stat-count" hides a diffstat for unmerged paths, the total number of affected files at the bottom of the "diff --stat" output was computed incorrectly.
"diff --shortstat" miscounted the total number of affected files when there were unmerged paths.
"git p4" used to try expanding malformed "$keyword$" that spans across multiple lines.
"git update-ref -d --deref SYM" to delete a ref through a symbolic ref that points to it did not remove it correctly.
Syntax highlighting in "gitweb" was not quite working.

Also contains other minor fixes and documentation updates.

Getting an ultrabook

2012-11-26T00:55:00.000-08:00

I've been happily using Dell Inspiron 1420, and it still is a fine laptop to run Linux on, but it started to feel a bit stale, especially with its 1280x800 display. So I got a Vizio CT15-A5.

Its 1920x1080 display was the primary reason I picked this over Lenovo X1 carbon, even though this is also quite larger; in fact, I do not think I would be willing to carry anything larger than this one.

Doesn't the manufacturer's logo look like U1210, as if it is screaming to get Ubuntu 12.10 installed?

Now, even though I am sufficiently old that tweaking machine configuration no longer excites me too much, I am still curious. It came with Windows 8 (without reinstallation medium). So instead of wiping and installing Ubuntu from scratch, I decided to keep the Windows for a while and see how it looks like, and dual-boot the machine.

Of course, before deciding that, I had to make sure that it worked with Ubuntu (which happened to be the distro I have been running on my 1420). Booting from USB key needed a bit of BIOS tweaking (and it came with no manual, so it needed a bit of Googling around to find out that hitting F2 was the way to fall into the bios settings screen while booting).

There are three places in the bios setting that affects the booting:

Secure boot (on/off)
OS support (Windows/other)
Boot device (USB key, USB CD, USB HDD, USB floppy, Internal HDD, UEFI Windows Boot Manager)

After a couple of trial and error sessions, I found out that in order to boot from the USB key, I had to (1) turn off Secure Boot, (2) pick "Other" from OS Support, and (3) have "USB key" early in the boot device order. In fact, it did not allow me to do (2) until I turned off Secure Boot.

It felt funny to boot the "try it out" mode from a USB key, install Chrome browser in that environment, adding a plugin to do video hangout for G+ in it, all without actually touching the internal disk at all. All the usual suspects in Linux portability (touchpad, wifi, webcam, speakers, microphone, etc.) seemed to work fine out of the box.

Booting into the Windows and looking at its disk (Win-R "diskmgmt.msc") reveals that it uses GPT partitioning scheme, with bunch of garbage partitions (300MB Recovery and 260MB ESP at the beginning, 6.8G Recovery and 2G OEM at the end, with all the remaining space allocated for Windows C:). It also seems that booting from the USB key puts it into BIOS (i.e. not UEFI) mode, so it is understandable that Ubuntu installation USB key said that it does not see any bootable operating system on the disk, and there needs a dedicated "bios_grub" partition.

As a smaller configuration of the same ultrabook ships with 128G SDD (I got a 256G version), it should be sufficient to give Windows (and all the other garbage partition) 128G or so. I shrunk C: to 64G, carved out 22G for Linux (root filesystem), 4G swap, and created a 140G "Data" partition to be shared between the dual booted OSes. Also I gave a few megabytes to the bios grub partition.

The configuration ended up a bit strange albeit a workable one. When the firmware is set to boot from the internal HDD, because Ubuntu installation wrote the early stage of grub into the MBR (without corrupting GPT), it boots into Ubuntu. When set to boot with UEFI, it boots into Windows. I am guessing that I could install rEFInd and always boot with UEFI to dual boot from there, but I haven't felt the need for that step yet.

For now, I still have the Windows installation. I can run Putty to ssh into my primary machine, I can run Gimp, LibreOffice and GnuCash locally. I haven't found something I have to boot into Ubuntu side of the system to do, so I might end up keeping the Windows side much longer than I was originally planning to. Besides, I'm tentatively enrolled in Amazon's Prime program, and their Prime instant video does not play on Chrome/Linux, so...

Git 1.8.0.1

2012-11-26T00:45:00.000-08:00

As I took a vacation for a few weeks after tagging Git 1.8.0 and needed about a week to sift through the backlog (although having an interim maintainer greatly helped in keeping track of topics in flight in the meantime), we have accumulated quite a few fixes since the major release on the 'master' front. These fixes have been merged to the 'maint' branch and there is the first maintenance release Git 1.8.0.1 now.

Please see the Announcement for details.