Monday, April 30, 2012

Naming a machine

When I came to Google, I asked my desktop machine to be named "linus". I was asked: "Do you really want your machine named linus?"

But the thing is, the requested name is not after Linus Torvalds. 
I name my machines using a dictionary. Let me explain how. I name my machines after some theme, and the machine "linus", just like my primary box "alter", is named after the primary activity I was planning to do on it, namely "Git".

The first thing to do is to find a bunch of dictionary words that have G, I and T in this order. We may find these words: afGhanIsTan, linGuIsT, aGlITter,...

Then remove these G, I and T from these dictionary words to obtain: afhansan, linus, alter,...

Finally, pick ones that can be pronounced and preferrably in dictionary.

That is how the machine was called "linus", and the primary box I use at home is "alter". My general purpose notebook is called "wing" (named after its manufacturer
—can you guess who?).


Needless to say, I already know the name of my next Git machine: dial.

How do you name your machine?


Sunday, April 29, 2012

Rebuilding Git Integration Environment

About ten days ago, after getting to the office, I found that my home box that I use as the primary integration machine was not responding. Later in the day, wife calls from home saying that the box is dead and does not even respond to the power button.

So until I had a chance to look at the box and resurrect it, I had to build the Git Integration Environment elsewhere. As Linus famously said once, only wimps use backup and real men just upload their important stuff and let the rest of the world mirror it ;-). All of my integration branches are pushed to multiple places, and one of the public repositories even have all of the topic branches, so it is just the matter of fetching them back. Other people could even try to imitate what I do by following this procedure.

First, grab all the branches I had in the primary box from the mirror:

$ git init git.git
$ cd git.git
$ git fetch --update-head-ok git://github.com/gitster/git refs/*:refs/*
$ git reset --hard master

Unfortunately, GitHub adds garbage refs to my repository that I didn't push; I can eradicate them like this, but this step is not strictly necessary:

$ for x in $(git for-each-ref --format='%(refname)' refs/pull/)
  do
    git update-ref -d $x
  done

After this, I can start building Git from tips of topic branches as usual, but my usual procedure is to make heavy use of helper scripts in the 'todo' branch that is checked out in the Meta directory (e.g. I run Meta/Make instead of make from the top-level, and that Make script is in the 'todo' branch).

$ git init Meta
$ (cd Meta && git pull git://git.kernel.org/pub/scm/git/git.git todo:master)
$ Meta/Make test install

Among the helper scripts on the 'todo' branch (and checked out in the Meta directory) is the Reintegrate script.  This is used to maintain redo-jch.sh and redo-pu.sh scripts I rebuild 'jch' and 'pu' branches with.

$ Meta/Reintegrate master..jch >Meta/redo-jch.sh
$ Meta/Reintegrate jch..pu >Meta/redo-pu.sh
$ chmod +x Meta/redo-*.sh

What is still missing after the above is the contents of the rerere database. This mechanism remembers the manual conflict resolution I had to perform when I built the integration branches (i.e. 'next', 'pu' and 'jch') earlier. Luckily, there is a script to do so in contrib/ since Sep 2008:

$ PATH=$PATH:. contrib/rerere-train.sh master..pu

This populates the rerere database by learning from the merge commits between 'master' and 'pu' branches, so after that, I can try rebuilding 'pu', like this:

$ git checkout master^0 ;# I am not really rebuilding--just "try rebuilding"
$ Meta/redo-jch.sh ;# replay all the merges that should go to the jch branch
$ Meta/redo-pu.sh ;# and then the merges to the pu branch on top
$ git diff HEAD pu ;# there should be no differences

After this, I can look at individual topics, decide which topics are worthy to be merged to 'next' or 'master', and advance tips of these integration branches with appropriate invocations of the git merge commands.

By the way, it turns out that the breakage was a failed power supply. I ordered one from NewEgg, which arrived early last week, but I procrastinated until this morning to replace it. After the necessary hardware swap,  running the above procedure again to get the environment back was more or less trivial.

So, it's Baaack ;-)

Thursday, April 26, 2012

Git 1.7.7.7, 1.7.8.6 and 1.7.9.7

New releases for the three older maintenance tracks have been tagged and tarballs uploaded. They were mostly to push out small documentation fixes that have already been in the 'master' branch for the next feature release, except for v1.7.9.7, which has a fix for performance regression in "git fetch" introduced some time ago where the command wastes cycles to verify the connectivity of objects received from the other end, being unnecessarily pessimistic.

Friday, April 6, 2012

Git 1.7.10

After slipping for about a week, 1.7.10 final has been tagged.

The most notable change is that from this release, git merge will start opening the editor just like git commit does. See earlier articles for details.


Git v1.7.10 Release Notes

=========================


Compatibility Notes
-------------------


 * From this release on, the "git merge" command in an interactive
   session will start an editor when it automatically resolves the
   merge for the user to explain the resulting commit, just like the
   "git commit" command does when it wasn't given a commit message.


   If you have a script that runs "git merge" and keeps its standard
   input and output attached to the user's terminal, and if you do not
   want the user to explain the resulting merge commits, you can
   export GIT_MERGE_AUTOEDIT environment variable set to "no", like
   this:


        #!/bin/sh
        GIT_MERGE_AUTOEDIT=no
        export GIT_MERGE_AUTOEDIT


   to disable this behavior (if you want your users to explain their
   merge commits, you do not have to do anything).  Alternatively, you
   can give the "--no-edit" option to individual invocations of the
   "git merge" command if you know everybody who uses your script has
   Git v1.7.8 or newer.


 * The "--binary/-b" options to "git am" have been a no-op for quite a
   while and were deprecated in mid 2008 (v1.6.0).  When you give these
   options to "git am", it will now warn and ask you not to use them.


 * When you do not tell which branches and tags to push to the "git
   push" command in any way, the command used "matching refs" rule to
   update remote branches and tags with branches and tags with the
   same name you locally have.  In future versions of Git, this will
   change to push out only your current branch according to either the
   "upstream" or the "current" rule.  Although "upstream" may be more
   powerful once the user understands Git better, the semantics
   "current" gives is simpler and easier to understand for beginners
   and may be a safer and better default option.  We haven't decided
   yet which one to switch to.




Updates since v1.7.9
--------------------


UI, Workflows & Features


 * various "gitk" updates.
   - show the path to the top level directory in the window title
   - update preference edit dialog
   - display file list correctly when directories are given on command line
   - make "git-describe" output in the log message into a clickable link
   - avoid matching the UNIX timestamp part when searching all fields
   - give preference to symbolic font names like sans & monospace
   - allow comparing two commits using a mark
   - "gitk" honors log.showroot configuration.


 * Teams for localizing the messages from the Porcelain layer of
   commands are starting to form, thanks to Jiang Xin who volunteered
   to be the localization coordinator.  Translated messages for
   simplified Chinese, Swedish and Portuguese are available.


 * The configuration mechanism learned an "include" facility; an
   assignment to the include.path pseudo-variable causes the named
   file to be included in-place when Git looks up configuration
   variables.


 * A content filter (clean/smudge) used to be just a way to make the
   recorded contents "more useful", and allowed to fail; a filter can
   now optionally be marked as "required".


 * Options whose names begin with "--no-" (e.g. the "--no-verify"
   option of the "git commit" command) can be negated by omitting
   "no-" from its name, e.g. "git commit --verify".


 * "git am" learned to pass "-b" option to underlying "git mailinfo", so
   that a bracketed string other than "PATCH" at the beginning can be kept.


 * "git clone" learned "--single-branch" option to limit cloning to a
   single branch (surprise!); tags that do not point into the history
   of the branch are not fetched.
 * "git clone" learned to detach the HEAD in the resulting repository
   when the user specifies a tag with "--branch" (e.g., "--branch=v1.0").
   Clone also learned to print the usual "detached HEAD" advice in such
   a case, similar to "git checkout v1.0".

 * When showing a patch while ignoring whitespace changes, the context
   lines are taken from the postimage, in order to make it easier to
   view the output.

 * "git diff --stat" learned to adjust the width of the output on
   wider terminals, and give more columns to pathnames as needed.

 * "diff-highlight" filter (in contrib/) was updated to produce more
   aesthetically pleasing output.

 * "fsck" learned "--no-dangling" option to omit dangling object
   information.

 * "git log -G" and "git log -S" learned to pay attention to the "-i"
   option.  With "-i", "log -G" ignores the case when finding patch
   hunks that introduce or remove a string that matches the given
   pattern.  Similarly with "-i", "log -S" ignores the case when
   finding the commit the given block of text appears or disappears
   from the file.

 * "git merge" in an interactive session learned to spawn the editor
   by default to let the user edit the auto-generated merge message,
   to encourage people to explain their merges better. Legacy scripts
   can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior.
   Both "git merge" and "git pull" can be given --no-edit from the
   command line to accept the auto-generated merge message.

 * The advice message given when the user didn't give enough clue on
   what to merge to "git pull" and "git merge" has been updated to
   be more concise and easier to understand.

 * "git push" learned the "--prune" option, similar to "git fetch".

 * The whole directory that houses a top-level superproject managed by
   "git submodule" can be moved to another place.

 * "git symbolic-ref" learned the "--short" option to abbreviate the
   refname it shows unambiguously.

 * "git tag --list" can be given "--points-at " to limit its
   output to those that point at the given object.

 * "gitweb" allows intermediate entries in the directory hierarchy
   that leads to a project to be clicked, which in turn shows the
   list of projects inside that directory.

 * "gitweb" learned to read various pieces of information for the
   repositories lazily, instead of reading everything that could be
   needed (including the ones that are not necessary for a specific
   task).

 * Project search in "gitweb" shows the substring that matched in the
   project name and description highlighted.

 * HTTP transport learned to authenticate with a proxy if needed.

 * A new script "diffall" is added to contrib/; it drives an
   external tool to perform a directory diff of two Git revisions
   in one go, unlike "difftool" that compares one file at a time.

Foreign Interface

 * Improved handling of views, labels and branches in "git-p4" (in contrib).

 * "git-p4" (in contrib) suffered from unnecessary merge conflicts when
   p4 expanded the embedded $RCS$-like keywords; it can be now told to
   unexpand them.

 * Some "git-svn" updates.

 * "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and
   support incremental imports.

 * "git difftool/mergetool" learned to drive DeltaWalker.
Performance

 * Unnecessary calls to parse_object() "git upload-pack" makes in
   response to "git fetch", have been eliminated, to help performance
   in repositories with excessive number of refs.

Internal Implementation (please report possible regressions)

 * Recursive call chains in "git index-pack" to deal with long delta
   chains have been flattened, to reduce the stack footprint.

 * Use of add_extra_ref() API is now gone, to make it possible to
   cleanly restructure the overall refs API.

 * The command line parser of "git pack-objects" now uses parse-options
   API.

 * The test suite supports the new "test_pause" helper function.

 * Parallel to the test suite, there is a beginning of performance
   benchmarking framework.

 * t/Makefile is adjusted to prevent newer versions of GNU make from
   running tests in seemingly random order.

 * The code to check if a path points at a file beyond a symbolic link
   has been restructured to be thread-safe.

 * When pruning directories that has become empty during "git prune"
   and "git prune-packed", call closedir() that iterates over a
   directory before rmdir() it.

Also contains minor documentation updates and code clean-ups.


Fixes since v1.7.9
------------------

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

 * Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work
   with versions of Perl older than 5.8.3.
   (merge 5eb660e ab/perl-i18n later to maint).

 * "git tag -s" honored "gpg.program" configuration variable since
   1.7.9, but "git tag -v" and "git verify-tag" didn't.
   (merge a2c2506 az/verify-tag-use-gpg-config later to maint).

 * "configure" script learned to take "--with-sane-tool-path" from the
   command line to record SANE_TOOL_PATH (used to avoid broken platform
   tools in /usr/bin) in config.mak.autogen.  This may be useful for
   people on Solaris who have saner tools outside /usr/xpg[46]/bin.

 * zsh port of bash completion script needed another workaround.

Tuesday, April 3, 2012

This time, it will be really final rc before Git 1.7.10

The upcoming version 1.7.10 of Git was scheduled to be tagged on Sunday, but I did not want to make important decisions or announces over the weekend to avoid making people wonder if anything I say is an April Fools joke.

That was an excuse for slipping the release a bit, but as a nice side effect, it paid off. Over the weekend, a few patches and a pull request worthy to be in the upcoming release came. A couple of rather embarrassing last-minute bugs were found and fixed in the updated gitk, and we have Portuguese translation of the messages.

So I am issuing another release candidate 1.7.10-rc4, hoping that people can test it out to find any other last-minute regressions, so that we can release the real 1.7.10 by the end of this week.