Git 1.8.1

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 

Is there any science in Amazon pricing?

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

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

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

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

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.

Git 1.8.0

Finally.

With help from 82 contributors since 1.7.12 release, and great help from countless reviewers on these changes, a new feature release Git 1.8.0 has been tagged with 497 new non-merge commits. Thanks everybody in the Git development community, and thanks for feature requests and bug reports for everobyd in various Git user communities.

Tarballs of the new release have been pushed out to the usual place, and the public repositories have the histories leading to this release.

For highlights, please refer to earlier entries. The final Release Notes describes everything in gory details.

I'll be on vacation for a few weeks, and I do not plan to carry a computer with me. In the meantime, Jeff King will be acting as an interim maintainer.

Here is a fun fact.

The very initial public appearance of Git consisted of 11 files, 1244 lines in total, v0.99~954 (Initial revision of "git", the information manager from hell, 2005-04-07).

Among these 1244 lines, there were 1065 non-empty lines, of which 206 lines still survive to date (v1.8.0).

   surviving     original path (survival%)
          14           40 Makefile (35.00%)
          16          168 README (9.52%)
          51           93 cache.h (54.83%)
           4           23 cat-file.c (17.39%)
           6          172 commit-tree.c (3.48%)
           4           51 init-db.c (7.84%)
          84          259 read-cache.c (32.43%)
           0           43 read-tree.c (0.00%)
           7           81 show-diff.c (8.64%)
          20          248 update-cache.c (8.06%)
           0           66 write-tree.c (0.00%)
         206         1244 Total (16.55%)

Note that this does not mean one sixth of 1.8.0 release was from Linus.

Git 1.8.0-rc2

Things seem to have calmed down and hopefully we can have the final 1.8.0 release without regression soon. Give it a final round of testing by grabbing it from the usual places. Tarballs are found here.

For highlights, please see this earlier post.

Git 1.8.0-rc1 and 1.7.12.3

A maintenance release 1.7.12.3 has been tagged with a handful of fixes that have been backported from the primary development branch.

On the primary development front, we now have the first release candidate 1.8.0-rc1. The final 1.8.0 is scheduled to be tagged on October 21st, 2012, and I'll disappear for a couple of weeks after that, so please help us find the last minute regressions and fix them, if any, in the coming two weeks.

The upcoming release consists of a finely balanced mix of bug-fixes, usability enhancements and surprising new features.

Some highlights:

• In the next major release (not the 1.8.0 release, but the one that follows it, perhaps 1.9 or 2.0), we will change the behavior of the "git push" command.  When "git push [$there]" does not say what to push, we have traditionally used the "matching" semantics (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 but 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 in 1.8.0 release, "git push" will start warning qabout the upcoming change until you set this variable.
• When "git am" is fed an input that has multiple "Content-type: ..." header, it did not grok charset= attribute correctly. It also mishandled a patch attached as application/octet-stream (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not honored correctly.
• Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the working tree version. The command has been updated to show cleanly merged parts as coming from the other branch that is being merged.
• "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.
• "git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order; now it replays them in the order the user told it to, i.e. "A C B", which is what the user naturally expects. 
• A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch" in the first place.
• "git log --all-match --grep=A --grep=B" ought to show commits that mention both A and B  but when these three options are used with --author or --committer, it showed commits that mention either A or B (or both) instead; this has been fixed.
• "git log -g" can be given "--grep-reflog=pattern" option to look for entries with strings that match the given pattern.
• The "-Xours" (and "-Xtheirs") backend option to "git merge -s recursive" now takes effect even on binary files.
• The sub-command in "git remote" to remove a defined remote was "rm" and the command did not take a fully-spelled "remove".
• The interactive prompt "git send-email" gives was error prone. It asked "What e-mail address do you want to use?" with the address it guessed (correctly) the user would want to use in its prompt, tempting the user to say "y". But the response was taken as "No, please use 'y' as my e-mail address instead", which is most certainly not what the user meant; the command asks for confirmation in such a case now.

Again, please help us find the last minute regressions and fix them, if any, in the coming two weeks.

Thanks.

Fun with running textconv

Today I met somebody and signed his PGP key. Then I thought I should check my own key, so I did this:

  $ gpg --recv-key 713660A7

which reported that I got a few new signatures.

I have my GnuPG keys in a Git repository. Out of habit, I did

  $ git diff -U0

and was pleasantly surprised to see:

  diff --git i/gnupg/pubring.gpg w/gnupg/pubring.gpg

  index 22b29b8..8beac85 100644

  --- i/gnupg/pubring.gpg

  +++ w/gnupg/pubring.gpg

  @@ -22,0 +23,1 @@ pub  4096R/713660A7 2011-10-01 Junio C Hamano

  +sig        00411886 2012-07-20   Linus Torvalds

  @@ -42,0 +44,1 @@ uid                            Junio C Hamano

  ...

in the output.

The surprise is not that I got a signature by Linus (I gave him the key fingerprint when I met him in person during OSCON week). It is that I am seeing a textual diff, which I completely forgot about having arranged to happen.

In the directory, I have this in the .gitattributes file:

  *ring.gpg       diff=gpg

and the repository has this in its .git/config file:

  [diff "gpg"]

          textconv = gpg -v

          xfuncname = "^((pub|uid) .*)"

These two, taken together, tells Git when comparing any file whose name matches "*ring.pgp", pass its contents to "gpg -v" command before running its comparison logic.  "gpg -v" command, when fed a keyring, shows the textual report of what is in the keyring, and that is how I get the above output. And the xfuncname thing tells Git to show the key's name on the @@ lines.

Fun ;-)

Counting log messages

Kees Cook made an interesting observation on his Google+ post.

$ git log --no-merges v3.5..v3.6 |egrep -i '(integer|counter|buffer|stack|fix) (over|under)flow' | wc -l

31

It finds phrases like "integer overflow", "fix underflow", etc. in the log messages of commits since v3.5 release up to v3.6 release.  There are 31 such phrases among 10k non-merge commits.

This however does not necessarily mean that there are 31 commits.  There only are 23 such commits (the "--grep=" option takes BRE, and syntactic metacharacters need to be quoted with backslashes), and you can count them like this:

$ git log --oneline --no-merges --regexp-ignore-case --grep='\(integer\|counter\|buffer\|stack\|fix\) \(over\|under\)flow' v3.5..v3.6 | wc -l 

23

This is because some commits have these phrases multiple times.  For example, commit dd03e734 reads like this:

mlx4_core: Fix integer overflows so 8TBs of memory registration works

This patch adds on the fixes done in commits 89dd86db78e0 ("mlx4_core:Allow large mlx4_buddy bitmaps") and 3de819e6b642 ("mlx4_core: Fix integer overflow issues around MTT table") so that memory registrationof up to 8TB (log_num_mtt=31) finally works.

It fixes integer overflows in a few mlx4_table_yyy routines in icm.cby using a u64 intermediate variable, and int/uint issues that causedtable indexes to become nagive by setting some variables to be u32instead of int.  These problems cause crashes when a user attempted toregister > 512GB of RAM.

Note that the regular expression used here does not catch when the phrase does not appear exactly as spelled in the log message. For example, it misses this:

mtdchar: fix offset overflow detection

Sasha Levin has been running trinity in a KVM tools guest, and was ableto trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of the memory type).  The call trace showed that it was mtdchar_mmap() that created an invalid remap_pfn_range().

To catch a commit with a log message like this, we can loosen the condition to say "the commit log must have one of these words (integer|counter|buffer|stack|fix), and also one of these words (overflow|underflow)".

The way to spell that is like this:

$ git log --all-match --no-merges --regexp-ignore-case \ 

  --grep='\(integer\|counter\|buffer\|stack\|fix\)' \

  --grep='\(over\|under\)flow' v3.5..v3.6

Each --grep= pattern match individually, and --all-match tells git log to show only commits for which all of the patterns trigger, and that is why this will find "fix" and "overflow" not next to each other.  With --oneline , this will count 53 commits.

By the way, I haven't written "Git guide" material on my blog for quite some time, and it shows. I need to practice writing a bit more.

Git 1.8.0-rc0

I just tagged Git 1.8.0-rc0. Tarballs are found at the usual place. The 1.8.0 is scheduled to appear on Oct 21 and I am planning to disappear for a few weeks after that on vacation.

Here are some highlights:

• In the next major release, 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 (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.
• "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.
• The "-Xours" (and "-Xtheirs") backend option to "git merge -s recursive" now takes effect even on binary files.
• Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the working tree version. The command has been updated to show cleanly merged parts as coming from the other branch that is being merged.
• "git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order; now it replays them in the order the user told it to, i.e. "A C B", which is what the user naturally expects. 
• "git log --all-match --grep=A --grep=B" ought to show commits that mention both A and B  but when these three options are used with --author or --committer, it showed commits that mention either A or B (or both) instead; this has been fixed.
• The interactive prompt "git send-email" gives was error prone. It asked "What e-mail address do you want to use?" with the address it guessed (correctly) the user would want to use in its prompt, tempting the user to say "y". But the response was taken as "No, please use 'y' as my e-mail address instead", which is most certainly not what the user meant; the command asks for confirmation in such a case now.

I've been doing "-rc0" since the Git version 1.5.0 era (that's almost 6 years).

It is easy to understand what "-rc1" is.  It is the first "release candidate". Some last-minute bugs and regressions are expected to be found in it, reported, fixed and will result in "-rc2", "-rc3", etc. until the final release, which hopefully is as close to perfect as we can make.

But what is "-rc0"?

I do not know about other projects, but in the context of Git, it is "a more or less feature complete preview of the upcoming release". There may still be a couple to several topics cooking on the 'next' branch that are to be merged before the real feature freeze ("-rc1"), but they are relatively minor that lacking them is not expected to change the overall end user experience too much from the final release.

And the 1.8.0-rc0 is such a preview. I am planning to merge two small features and two fixes later this week when I tag 1.8.0-rc1, but other than these four topics, what has been tagged today is more or less a good preview for the final release (modulo bugs and regressions that will be fixed, if any, before the real thing).

That means that it is very important for the users to test and find regressions in this preview. If you are using Git, please take some time and do your part to help the upcoming release as polished as we could.

Thanks.

Git 1.7.12.2

The second maintenance release in Git 1.7.12.X series has been tagged, with a handful of further bugfixes that have been cooking in the master branch for the upcoming feature release Git 1.8.0.

Some highlights:

• When "git am" is fed an input that has multiple "Content-type: ..."  header, it did not grok charset= attribute correctly.
• Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the "working tree" version; make it more useful by showing cleanly merged parts as coming from the other branch that is being merged.
• "git blame MAKEFILE" run in a history that has "Makefile" but not "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got confused on a case insensitive filesystem and failed to do so.
• "git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags").
• "git log/diff/format-patch --stat" showed the "N line(s) added" comment in user's locale and caused careless submitters to send patches with such a line in them to projects whose project language is not their language, mildly irritating others. Localization to the line has been disabled for now.
• "git log --all-match --grep=A --grep=B" ought to show commits that mention both A and B, but when these three options are used with --author or --committer, it showed commits that mention either A or B (or both) instead.
• The subcommand to remove the definition of a remote in "git remote" was named "rm" even though all other subcommands were spelled out.  Introduce "git remote remove" to remove confusion, and keep "rm" as a backward compatible synonym.

Upgrade and enjoy.

Git User's Survey 2012 edition

This year's Git User's Survey is now up, thanks to a contributor Jakub Narębski.

Please devote a few minutes of your time to fill out the simple questionnaire; it'll help the Git community understand what you do with Git, what you like about Git (and what you don't), and overall will help us improve the system.

Thanks.

Git 1.7.12.1

The first maintenance release for Git 1.7.12.X series has been tagged, with many usability fixes that have been cooking in the 'next'/'master' front (they will all be in the upcoming major release 1.8.0).

All users of 1.7.12.X series must upgrade (eh, must is not quite true, but I just wanted to say it after seeing Greg-KH doing so on the kernel mailing list).

Some highlights:

• "git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. This has been fixed.
  
• "git for-each-ref" did not correctly support more than one --sort option.
  
• When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol.
  
• The interactive prompt "git send-email" gives was error prone. It asked "What e-mail address do you want to use?" with the address it guessed (correctly) the user would want to use in its prompt, tempting the user to say "y". But the response was taken as "No, please use 'y' as the e-mail address instead", which is most certainly not what the user meant. We now ask for confirmation against such input.
  
• After "gitk" showed the contents of a tag, neither "Reread references" nor "Reload" did not update what is shown as the contents of it, when the user overwrote the tag with "git tag -f".

Please see the full changelog for details.

Enjoy.

Git 1.7.12

I just tagged the 1.7.12 final release, which is available in tarball form here, and from the usual copies of my repository.

Some highlights:

• An experimental support for UTF-8 pathnames on MacOS.
  I think there still are places that need conversion between the system encoding (UTF-8 normalized by decomposing) and the more commonly used encoding (precomposed) that is used internally for better interoperability, but this should be a good start.
• $HOME/.gitconfig file can be moved to $HOME/.config/git/config, in line with XDG.
  This will also allow $HOME/.config/git/attributes and $HOME/.config/git/ignore, if exist, to be automatically used as core.attributesfile and core.excludesfile, respectively.
• "git apply" learned the same three-way merge patch wiggling magic "git am" supports, via the "-3" option.
• "git rebase -i --root" learned how to update the root commit when requested.
• "git status" can give a more detailed explanation during "intermediate" state of multi-step operations, e.g. "merge", "rebase".
• A remote "SCM" interface to MediaWiki in contrib/ learned to handle file attachments.
• "git clone --no-local $path" bypasses the "local directory?  Just cp -R it!" (not quite that aggressive, but still) optimization and invokes the usual object transfer and repacking codepath.
• The HTMLified documentation pages shown by "git help -w $cmd" could be obtained over the network by setting the help.htmlpath configuration variable.

Enjoy.

Git 1.7.11.5 and Git 1.7.12-rc3

The final release candidate for 1.7.12 is found at the usual places. Again, nothing earth-shattering.

For highlights of the upcoming release, please see the previous entry on 1.7.12-rc1.

Also there is an updated maintenance release 1.7.11.5 that fixes some minor build issues, with updates to "git-blame.el" (in contrib/).

Leftover bits

While developing for Git, sometimes I find a topic getting "stuck" for various reasons, e.g. the basic direction is good, but the remainder of the system is not ready for such a change.

Instead of running "git branch -D topic" in such a case, I use a "git hold" alias that looks like this:

[alias]
  hold = "!sh -c 'git update-ref refs/hold/$1 refs/heads/$1 && \
          git branch -D $1' -"

to stash it away. And "git for-each-ref refs/hold/" gives me many such "held" topics.

Of course, without an active effort to go back, reconsider and prune from time to time, these things tend to accumulate. And today was a good day to review them for me. I found a couple of topics that may still be viable as my reward:

• [DONE - will be in Git 2.0] Make "git add " notice removals of files in the named directories; after all "add" is not about "add files to git", but is "add the current state to the index", and the lack of files that previously existed is part of that state.
  Cf. $gmane/171811
  
  
• [DONE] Allow "git log .." to mean "Give me a log of recent commits that touch my parent directory and what are under it". The current code instead insists that ".." could be both a revision range and a path and asks the user to disambiguate.
  Cf. $gmane/172619

I did not find major downsides on either of these topics after re-thinking the issues, and I didn't see any valid objections from people whose judgement I trust in the old discussions, either.

Perhaps I should try resurrecting them and see what happens.

Git 1.7.12-rc2

An updated release candidate is found at the usual places. You should find nothing earth-shattering in there; just a bunch of translation updates, build clean-ups, and minor documentation updates.

For highlights of the upcoming release, please see the previous entry on 1.7.12-rc1.

Bringing a bit more sanity to "alternates"?

The "alternates" mechanism lets you keep a single object store (not necessarily a git repository on its own, but just the objects/ part of it) on a machine, have multiple repositories on the same machine share objects from it, to save the network transfer bandwidth when cloning from remote repositories and the disk space used by the local repositories.  A repository created by "clone --reference" or "clone -s" uses this mechanism to borrow objects from the object store of another repository.  A user also can manually add new entries to $GIT_DIR/objects/info/alternates to borrow from other object stores.

The UI for this mechanism however has some room for improvement, and we may want to start improving it for the next release after the upcoming Git 1.7.12 (or even Git 2.0 if the change is a large one that may be backward incompatible but gives us a vast improvement).

Here are some random thoughts as a discussion starter (the real discussion is on the git mailing list git@vger.kernel.org; see http://thread.gmane.org/gmane.comp.version-control.git/202902).

By design, the borrowed object store MUST not ever lose any object from it, as such an object loss can corrupt the borrowing repositories.  In theory, it is OK for the object store whose objects are borrowed by repositories to acquire new objects, but losing existing objects is an absolute no-no.

But the UI of "clone -s" encourages users to borrow from the object store of a repository that the user may actively develop in.  It is perfectly normal for users to perform operations that make objects that used to be reachable from tips of its branches unreachable (e.g. rebase, reset, "branch -d") in a repository that is used for active development, but a "gc" after such an operation will lose objects that were originally available in the repository.  If objects lost that way were still needed by the repositories that borrow from it, the borrowing repository gets corrupt immediately.

In practice, this means that users who use "clone -s" to make a new repository can *never* prune the original repository without risking to corrupt its borrowing repository [1].
Some ideas:

• Make "clone --reference" without "-s" not to borrow from the reference repository.  E.g. if you have a clone of Linus repository at /git/linux.git/, cloning a related repository using it as --reference:
  
  $ git clone --reference /git/linux.git git://k.org/linux-next.git should still take advantage of /git/linux.git/{refs,objects} to reduce the transfer cost of fetching from k.org, but the resulting repository should not point /git/linux.git with its objects/info/alternates file.
• Make the distinction between a regular repository and an object store that is meant to be used for object sharing stronger.
  Perhaps a configuration item "core.objectstore = readonly" can be introduced, and we forbid "clone -s" from pointing at a repository without such a configuration.  We also forbid object pruning operations such as "gc" and "repack" from being run in a repository marked as such.
  
  It may be necessary to allow some special kind of repacking of such a "readonly" object store, in order to reduce the number of packfiles (and get rid of loose object files); it needs to be implemented carefully not to lose any object, regardless of local reachability.

When you have a repository and one or more repositories that borrow from it, you may want to dissociate the borrowing repositories from the borrowed one (e.g. so that you can repack or prune the original repository safely, or you may even want to remove it).

I think "git repack -a -d [-f]" in the borrowing repository happens to be the way to do this, but it is not clear to the users why.

Some ideas:

• It might not be a bad idea to have a dedicated new command to help users manage alternates ("git alternates"?); obviously this will be one of its subcommand "git alternates detach" if we go that route.
• Or just an entry in the documentation is sufficient?

When you have two or more repositories that do not share objects, you may want to rearrange things so that they share their objects from a single common object store.

There is no direct UI to do this, as far as I know.  You can obviously create a new bare repository, push there from all of these repositories, and then borrow from there, e.g.

git --bare init shared.git &&
for r in a.git b.git c.git ...
        do
   (
cd "$r" &&
       git push ../shared.git "refs/*:refs/remotes/$r/*" &&
echo ../../../shared.git/objects >.git/objects/info/alternates
       )
done

And then repack shared.git once.

Some ideas:

• (obvious: give a canned command to do the above, perhaps then set the core.objectstore=readonly in the resuting shared.git)

When you have one object store and a repository that does not yet borrow from it, you may want to make the repository borrow from the object store.  Obviously you can run "echo" like the sample script in the previous item above, but it is not obvious how to perform the logical next step of shrinking $GIT_DIR/objects of the repository that now borrows the objects.

[edit: This is supported as "git repack -a -d -l"]

I think "git repack -a -d" is the way to do this, but if you compare this command to "git repack -a -d -f" we saw previously in this message, it is not surprising that the users would be confused---it is not obvious at all.

Some ideas:

• (obvious: give a canned subcommand to do this)

[Footnote]

1 Making the borrowed object store aware of all the repositories that borrow from it, so that operations like "gc" and "repack" in the repository with the borrowed object store can keep objects that are needed by borrowing repositories, is theoretically possible, but is not a workable approach in practice, as (1) borrowers may not have a write access to the shared object store to add such a back pointer to begin with, (2) "gc"/"repack" in the borrowed object store and normal operations in the borrowing repositories can easily race with each other, without any coordination between the users, and (3) a casual "borrowing" can simply be done with a simple "echo" as shown in the main text of this message, and there is no way to ensure a backpointer from the borrowed object store to such a borrowing repository.

Git 1.7.12-rc1

The first release candidate for the upcoming Git 1.7.12 can be found at

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

and also at the usual repositories.

Some highlights:

• An experimental support for UTF-8 pathnames on MacOS.
  I think there still are places that need conversion between the system encoding (UTF-8 normalized by decomposing) and the more commonly used encoding (precomposed) that is used internally for better interoperability, but this should be a good start.
• $HOME/.gitconfig file can be moved to $HOME/.config/git/config, in line with XDG.
  This will also allow $HOME/.config/git/attributes and $HOME/.config/git/ignore, if exist, to be automatically used as core.attributesfile and core.excludesfile, respectively.
• "git apply" learned the same three-way merge patch wiggling magic "git am" supports, via the "-3" option.
• "git rebase -i --root" learned how to update the root commit when requested.
• "git status" can give a more detailed explanation during "intermediate" state of multi-step operations, e.g. "merge", "rebase".
• A remote "SCM" interface to MediaWiki in contrib/ learned to handle file attachments.

Please test so that we can avoid regressions in the final release that will happen late August.

Thanks.

Git 1.7.11.4

The fourth maintenance release for 1.7.11.x series has been tagged and is available at

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

It updates 1.7.11.3 with a handful of updates. The most notable one may be that you can now run filter-branch across a commit whose committer timestamp is in year 1970 (more precisely, the UNIX epoch).

Git 1.7.12-rc0

A release-candidate preview for the upcoming 1.7.12 has been tagged. The release tarballs are found at:

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

as usual.

Git v1.7.12 Release Notes (draft)

Updates since v1.7.11

UI, Workflows & Features

• Git can be told to normalize pathnames it read from readdir(3) and all arguments it got from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8), in order to work around issues on Mac OS.
• I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction.
• Per-user $HOME/.gitconfig file can optionally be stored in $HOME/.config/git/config instead, which is in line with XDG.
• The value of core.attributesfile and core.excludesfile default to $HOME/.config/attributes and $HOME/.config/ignore respectively when these files exist.
• Logic to disambiguate abbreviated object names have been taught to take advantage of object types that are expected in the context, e.g. XXXXXX in the "git describe" output v1.2.3-gXXXXXX must be a commit object, not a blob nor a tree.  This will help us prolong the lifetime of abbreviated object names.
• "git apply" learned to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have.
• Scripted Porcelain writers now have access to the credential API via the "git credential" plumbing command.
• "git clone --local $path" started its life as an experiment to optionally use link/copy when cloning a repository on the disk, but we didn't deprecate it after we made the option a no-op to always use the optimization.  The command learned "--no-local" option to turn this off, as a more explicit alternative over use of file:// URL.
• "git fetch" and friends used to say "remote side hung up unexpectedly" when they failed to get response they expect from the other side, but one common reason why they don't get expected response is that the remote repository does not exist or cannot be read. The error message in this case was updated to give better hints to the user.
• "git help -w $cmd" can show HTML version of documentation for "git-$cmd" by setting help.htmlpath to somewhere other than the default location where the build procedure installs them locally; the variable can even point at a http:// URL.
• "git rebase [-i] --root $tip" can now be used to rewrite all the history leading to "$tip" down to the root commit.
• "git rebase -i" learned "-x " to insert "exec " after each commit in the resulting history.
• "git status" gives finer classification to various states of paths in conflicted state and offer advice messages in its output.
• "git submodule" learned to deal with nested submodule structure where a module is contained within a module whose origin is specified as a relative URL to its superproject's origin.
• A rather heavy-ish "git completion" script has been split to create a separate "git prompting" script, to help lazy-autoloading of the completion part while making prompting part always available.
• "gitweb" pays attention to various forms of credits that are similar to "Signed-off-by:" lines in the commit objects and highlights them accordingly.

Foreign Interface

• "mediawiki" remote helper (in contrib/) learned to handle file attachments.
• "git p4" now uses "Jobs:" and "p4 move" when appropriate.
• vcs-svn has been updated to clean-up compilation, lift 32-bit limitations, etc.

Performance, Internal Implementation, etc. (please report possible regressions)

• Some tests showed false failures caused by a bug in ecryptofs.
• We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style.
• "git am --rebasing" codepath was taught to grab authorship, log message and the patch text directly out of existing commits.  This will help rebasing commits that have confusing "diff" output in their log messages.
• "git index-pack" and "git pack-objects" use streaming API to read from the object store to avoid having to hold a large blob object in-core while they are doing their thing.
• Code to match paths with exclude patterns learned to avoid calling fnmatch() by comparing fixed leading substring literally when possible.
• "git log -n 1 -- rarely-touched-path" was spending unnecessary cycles after showing the first change to find the next one, only to discard it.

Also contains minor documentation updates and code clean-ups.

Fixes since v1.7.11

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

• "git commit-tree" learned a more natural "-p " order of arguments long time ago, but recently forgot it by mistake.  (merge 4b7518a kk/maint-commit-tree later to maint).
• "git diff --no-ext-diff" did not output anything for a typechange filepair when GIT_EXTERNAL_DIFF is in effect.  (merge c12f82a jv/maint-no-ext-diff later to maint).
• When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it.  (merge 14bf2d5 pg/maint-1.7.9-am-where-is-patch later to maint).
• When "git submodule add" clones a submodule repository, it can get confused where to store the resulting submodule repository in the superproject's .git/ directory when there is a symbolic link in the path to the current directory.  (merge 6eafa6d jl/maint-1.7.10-recurse-submodules-with-symlink later to maint).
• In 1.7.9 era, we taught "git rebase" about the raw timestamp format but we did not teach the same trick to "filter-branch", which rolled a similar logic on its own.  (merge 44b85e89 jc/maint-filter-branch-epoch-date later to maint).

Git 1.7.11.3

The third maintenance release for 1.7.11 has been tagged and is available at the usual places (see Git Public Repositories link).

• The error message from "git push $there :bogo" (and its equivalent "git push $there --delete bogo") mentioned that we tried and failed to guess what ref is being deleted based on the LHS of the refspec, which we don't.
• A handful of files and directories we create had tighter than necessary permission bits when the user wanted to have group writability (e.g. by setting "umask 002").
• "commit --amend" used to refuse amending a commit with an empty log message, with or without "--allow-empty-message".
• "git commit --amend --only --" was meant to allow "Clever" people to rewrite the commit message without making any change even when they have already changes for the next commit added to their index, but it never worked as advertised since it was introduced in 1.3.0 era.
• Even though the index can record pathnames longer than 1<<12 bytes, in some places we were not comparing them in full, potentially replacing index entries instead of adding.
• "git show"'s auto-walking behaviour was an unreliable and unpredictable hack; it now behaves just like "git log" does when it walks.
• "git diff", "git status" and anything that internally uses the comparison machinery was utterly broken when the difference involved a file with "-" as its name.  This was due to the way "git diff --no-index" was incorrectly bolted on to the system, making any comparison that involves a file "-" at the root level incorrectly read from the standard input.
• We did not have test to make sure "git rebase" without extra options filters out an empty commit in the original history.
• "git fast-export" produced an input stream for fast-import without properly quoting pathnames when they contain SPs in them.
• "git checkout --detach", when you are still on an unborn branch, should be forbidden, but it wasn't.
• Some implementations of Perl terminates "lines" with CRLF even when the script is operating on just a sequence of bytes.  Make sure to use "$PERL_PATH", the version of Perl the user told Git to use, in our tests to avoid unnecessary breakages in tests.

The release tarballs are found at:

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

On the 'master' front, we are getting very close to the next feature release 1.7.12.

Git 1.7.11.2

The second maintenance release for 1.7.11 has many real fixes (the first one was mainly to fix the HTML formatted documentation pages) to bugs identified, diagnosed and fixed in the past three weeks. These fixes have been cooking on the master front for some time.

• On Cygwin, the platform pread(2) is not thread safe, just like our own compat/ emulation, and cannot be used in the index-pack program.  Makefile variable NO_THREAD_SAFE_PREAD can be defined to avoid use of this function in a threaded program.
• "git add" allows adding a regular file to the path where a submodule used to exist, but "git update-index" does not allow an equivalent operation to Porcelain writers.
• "git archive" incorrectly computed the header checksum; the symptom was observed only when using pathnames with hi-bit set.
• "git blame" did not try to make sure that the abbreviated commit object names in its output are unique.
• Running "git bundle verify" on a bundle that records a complete history said "it requires these 0 commits".
• "git clone --single-branch" to clone a single branch did not limit the cloning to the specified branch.
• "git diff --no-index" did not correctly handle relative paths and did not correctly give exit codes when run under "--quiet" option.
• "git diff --no-index" did not work with pagers correctly.
• "git diff COPYING HEAD:COPYING" gave a nonsense error message that claimed that the treeish HEAD did not have COPYING in it.
• When "git log" gets "--simplify-merges/by-decoration" together with "--first-parent", the combination of these options makes the simplification logic to use in-core commit objects that haven't been examined for relevance, either producing incorrect result or taking too long to produce any output.  Teach the simplification logic to ignore commits that the first-parent traversal logic ignored when both are in effect to work around the issue.
• "git ls-files --exclude=t -i" did not consider anything under t/ as excluded, as it did not pay attention to exclusion of leading paths while walking the index.  Other two users of excluded() are also updated.
• "git request-pull $url dev" when the tip of "dev" branch was tagged with "ext4-for-linus" used the contents from the tag in the output but still asked the "dev" branch to be pulled, not the tag.

As usual, the release tarballs are found at:

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

and the following public repositories all have a copy of the v1.7.11.2 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

Git 1.7.11.1

It is a bit embarrassing but it turns out that all cross links in the HTML version of manual pages in Git 1.7.11 were missing, so a brown-paper-bag maintenance release 1.7.11.1 is out.

Git 1.7.10.4 and Git 1.7.11-rc1

All the fixes to 1.7.10.x maintenance track that have been cooking on the master branch have also been merged and 1.7.10.4 release has been pushed out. Hopefully this will be the last release from the 1.7.10.x track. For the list of changes in this release, please see its release notes.


Finally 1.7.11-rc1 has been tagged. We originally wanted to keep this cycle on the shorter side of the 8-10 week release cycle, so that the end of the next cycle would coincide better with the end of GSoC, but it appears that it is looking like somewhat a lost cause. In any case, this marks the end of feature tweaks and bugfixes in this cycle and the focus shifts to finding and fixing regressions introduced since 1.7.10.

Please download, build and test the release candidate so that users do not have to suffer from regressions in the final 1.7.11 release.

Git 1.7.10.3 and Git 1.7.11-rc0

Two releases for a day.

The third maintenance release for 1.7.10.X series fixes a handful of regressions in previous 1.7.10.X releases.

On the master front, 1.7.11-rc0 is out.  Treat it as a preview of the real release candidate for the next big release—there still are several topics cooking in the next branch to shake out possible new bugs to make sure we can have a solid 1.7.11 release.

The most notable, from the long-term point of view, is the introduction of the simple push mode (credit goes to Matthieu Moy), which would hopefully prove to be a good default for new users until they configure the push.default to suit the requirement of their project.  With this, running git push or git push origin without saying which branches and/or tags to update what on the remote side from either command line or from the remote.$name.push configuration will only push the current branch to the branch of the same name on the other side, but only if the current branch is configured to use the branch on the other side as its upstream.

Have fun.

Git 1.7.10.1

The first maintenance release for 1.7.10.x series is out.



Git v1.7.10.1 Release Notes
===========================


Additions since v1.7.10
-----------------------


Localization message files for Danish and German have been added.




Fixes since v1.7.10
-------------------


 * "git add -p" is not designed to deal with unmerged paths but did
   not exclude them and tried to apply funny patches only to fail.


 * "git blame" started missing quite a few changes from the origin
   since we stopped using the diff minimalization by default in v1.7.2
   era.


 * When PATH contains an unreadable directory, alias expansion code
   did not kick in, and failed with an error that said "git-subcmd"
   was not found.


 * "git clean -d -f" (not "-d -f -f") is supposed to protect nested
   working trees of independent git repositories that exist in the
   current project working tree from getting removed, but the
   protection applied only to such working trees that are at the
   top-level of the current project by mistake.


 * "git commit --author=$name" did not tell the name that was being
   recorded in the resulting commit to hooks, even though it does do
   so when the end user overrode the authorship via the
   "GIT_AUTHOR_NAME" environment variable.


 * When "git commit --template F" errors out because the user did not
   touch the message, it claimed that it aborts due to "empty
   message", which was utterly wrong.


 * The regexp configured with diff.wordregex was incorrectly reused
   across files.


 * An age-old corner case bug in combine diff (only triggered with -U0
   and the hunk at the beginning of the file needs to be shown) has
   been fixed.


 * Rename detection logic used to match two empty files as renames
   during merge-recursive, leading to unnatural mismerges.


 * The parser in "fast-import" did not diagnose ":9" style references
   that is not followed by required SP/LF as an error.


 * When "git fetch" encounters repositories with too many references,
   the command line of "fetch-pack" that is run by a helper
   e.g. remote-curl, may fail to hold all of them. Now such an
   internal invocation can feed the references through the standard
   input of "fetch-pack".


 * "git fetch" that recurses into submodules on demand did not check
   if it needs to go into submodules when non branches (most notably,
   tags) are fetched.


 * "log -p --graph" used with "--stat" had a few formatting error.


 * Running "notes merge --commit" failed to perform correctly when run
   from any directory inside $GIT_DIR/.  When "notes merge" stops with
   conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
   to resolve it.


 * The 'push to upstream' implementation was broken in some corner
   cases. "git push $there" without refspec, when the current branch
   is set to push to a remote different from $there, used to push to
   $there using the upstream information to a remote unreleated to
   $there.


 * Giving "--continue" to a conflicted "rebase -i" session skipped a
   commit that only results in changes to submodules.


Also contains minor fixes and documentation updates.