git hints (cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory)

[Bob Proulx]

Since use of git is still new to many people on the list I thought I
reply with some general git hints for folks that might be following
along.  If you are already a git wizard then this won't be interesting
to you.

Jim Meyering wrote:
> Andreas Schwab <address@hidden> wrote:
> > A freshly checked out tree fails to bootstrap.
> 
> Thanks for reporting it.
> I noticed not long after the gnulib change that provoked it,
> and Bob Proulx tracked it down to this seemingly-innocuous change:
> 
>   commit d5daff19f4a26e67e7c410cefa9ddc13e036162a
>   Author: Bruno Haible <address@hidden>
>   Date:   Mon Oct 29 12:55:44 2007 +0100
> 
>     If --lgpl is not specified, convert copyright headers to GPLv3+.

Individual commits can be viewed using the git-show command.  Either
the full commit signature or enough to be unique.  I am just going to
use the first few characters here.

  $ git show d5daff19
  ...patch-like output...

This will be automatically piped to your pager (in my case 'less') and
so it is not necessary to explicitly pipe it to one.

> Although a gnulib change provoked the failure, I think bootstrap
> needs to change now that cjk.h is generated via a different code path,
> but haven't looked into it yet.
> 
> For now, you should be able to work around it by doing this first:
> 
>   mkdir lib/uniwidth

Or alternatively since there are only three commits in the upstream
gnulib since this failure I have simply been building using the
previous version of gnulib from version control.  In my mind the whole
purpose of version control is to create a safety net so that when a
new change causes a problem that it can be easily dealt with by using
previous known good versions.  Since I am building with a separate
gnulib in its own directory the version of gnulib can be selected
separately from the version of coreutils.  I am building coreutils
using the './bootstrap --gnulib-src=../gnulib' option.

  $ cd ../gnulib
  $ git checkout -b gnulib-ss-working d5daff19^

By using '^' at the end this checks out the version above/before that
version.  This selects the last version that built successfully.  This
could easily have been 28d9a006 too since d5daff19^ means 28d9a006 in
the gnulib history.  (And of course the full long commit signature
could have been used, as from a cut-n-paste, too.  I just shortened it
to make this message more readable.)

The 'git-checkout -b gnulib-ss-working' creates a branch and names it
"gnulib-ss-working".  This is necessary because git requires this to
be a branch head where more versions _could_ be committed and the
original "master" head already has commits after this point in the
branch and so a new branch just to hold this must be created.

When the gnulib problem is resolved this can be pulled back up to the
latest "HEAD" of the branch.

  $ git checkout master

After returning to the master branch's HEAD version the "topic branch"
is no longer needed.  It can be removed to clean it up.

  $ git branch -d gnulib-ss-working

Using git to find these types of failures is made easier by the
git-bisect command in git.  This command handles the topic branches
during the reduction process automatically.  The idea is that if you
have a point in time where things are one way (let's say working) and
another point in time where things are another way (say not working)
then you can perform a binary search through the list of versions
between those two points and very quickly find the version where
things change with a very few number of build attempts.  I knew
cd6b82c9 was a good version and planned to start the search there.

  git-rev-list cd6b82c9..master | wc -l
  18

With 18 potential versions to test I wanted to reduce the number of
potential build and test cycles and used git-bisect.  Here is how a
typical session goes.

  $ git checkout master
  $ git bisect start
  $ git bisect bad HEAD
  $ git bisect good cd6b82c9
  Bisecting: 9 revisions left to test after this
  ...test...
  $ git bisect good
  Bisecting: 5 revisions left to test after this
  ...test...
  $ git bisect good
  Bisecting: 2 revisions left to test after this
  ...test...
  $ git bisect bad
  Bisecting: 1 revisions left to test after this
  ...test...
  $ git bisect good
  d5daff19f4a26e67e7c410cefa9ddc13e036162a is first bad commit
  ...use this version for a bit...

Out of 18 versions the change was found in four test cycles.

At any time during the testing you can invoke 'git-bisect visualize'
to start up a 'gitk' visualizer to display graphically the versions
that are in the suspected version list.

This operates on a "bisect" branch.  When done use 'git bisect reset'
to clean up and return to the master branch on the branch head.

  $ git bisect reset  # all done

Bob