[PATCH] GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries

Regarding the new environment variable, Linus Torvalds <torvalds@linux-foundation.org> writes on Tue, 30 Mar 2010 in <alpine.LFD.2.00.1003301537150.3707@i5.linux-foundation.org>:

    I suspect that it is _very_ unusual to have a source repo that crosses
    multiple filesystems, and the original reason for this patch-series
    seems to me to be likely to be more common than that multi-fs case. So
    having the logic go the other way would seem to match the common case,
    no?

The "crossing filesystem boundary" condition is checked by comparing st_dev field in the result from stat(2). This is slightly worrysome if non-POSIX ports return different values in the field even for directories in the same work tree extracted to the same "filesystem". Erik Faye-Lund confirms that in the msysgit port st_dev is 0, so this should be safe, as "even Windows is safe" ;-)

This will affect those who use /.git to cram /etc and /home/me in the same repostiory, /home is mounted from non-root filesystem, and a git operation is done from inside /home/me/src. But that is such a corner case we don't want to give preference over helping people who will benefit from having this default so that they do not have to suffer from slow automounters.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I agree with Linus that it make sense to flip the default, but this
   should probably have to wait for at least two release cycles for the
   usual backward-compatibility rules.

   I wonder if "git add" and friends should also notice it and warn.  If
   you have more than one values of ce->ce_dev in the index, it means that
   the working tree spans more than one filesystem and from a subdirectory
   with an entry that has a ce->ce_dev different from the value for a path
   at the top of the work tree, you will not be able to discover the top
   of the tree without GIT_ONE_FILESYSTEM set to true.  A likely scenario
   for this to happen would be:

    (1) You have a tarball of some sort; you extract it $there;

	$ mkdir $there && cd $there
        $ tar xf /var/tmp/tarball.tar

    (2) You notice the filesystem lacks enough free space, and move some
        part (say "images/") to a separate filesystem, and bind-mount;

        $ mv images $another/. && rm -fr images && mkdir images
        $ mount --bind $another/images images

    (3) You add everything to start the project;

        $ git init && git add .

        Up to this point it would work (you are at the top of the working
        tree).  And this is the point we _could_ notice and warn that you
        will have trouble in step (4).

    (4) Go down to a subdirectory and start futzing;

	$ cd images && gimp naughty.jpg && git add -u

 Documentation/git.txt |   12 ++++++++----
 setup.c               |    4 ++--
 2 files changed, 10 insertions(+), 6 deletions(-)