patch, 3 partstruncate cwd string before printing error message

Here's another try for GIT_ONE_FILESYSTEM.

I took Duy's recommendation not to die() in gentle mode as well as to just use cwd in my error messages (after truncating them). I also fixed the problem with the existing error message's use of an untruncated cwd.

Thanks for all of the suggestions!

Lars R. Damerow (3):
      config.c: remove static keyword from git_env_bool()
      truncate cwd string before printing error message
      Add support for GIT_ONE_FILESYSTEM

 Documentation/git.txt |    3 +++
 cache.h               |    1 +
 config.c              |    2 +-
 setup.c               |   28 +++++++++++++++++++++++++++-
 4 files changed, 32 insertions(+), 2 deletions(-)

Since this function is the preferred way to handle boolean environment variables it's useful to have it available to other files.

Signed-off-by: Lars R. Damerow <lars@pixar.com>
---
 cache.h  |    1 +
 config.c |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

Without this truncation the error message printed only shows the cwd from the start of the search, not where it failed.

Signed-off-by: Lars R. Damerow <lars@pixar.com>
---
 setup.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

This patch makes git pay attention to the GIT_ONE_FILESYSTEM environment variable. When that variable is set, git will stop searching for a GIT_DIR when it attempts to cross a filesystem boundary.

When working in an environment with too many automount points to make maintaining a GIT_CEILING_DIRECTORIES list enjoyable, GIT_ONE_FILESYSTEM gives the option of turning all such attempts off with one setting.

Signed-off-by: Lars R. Damerow <lars@pixar.com>
---
 Documentation/git.txt |    3 +++
 setup.c               |   24 ++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)

On Wed, Mar 17, 2010 at 12:55:53PM -0700, Lars R. Damerow wrote:

Thanks, this version (and the whole series) looks good to me, with two minor nits below.

As far as a command-line option or a config option, I don't see the point. It seems to me something you would want enabled all the time, not a one-shot option, so a command-line option doesn't make much sense (after all, you could just use --git-dir at that point, which would be even faster). A config option might be useful, but I think it might be tricky to implement due to the startup sequence. If anybody disagrees, they can always build on top of your series very easily.

We should give the user a little more information than that. Specifically:

  - what form should the value take?

  - how does it interact with GIT_DIR?

Also, we use the phrase "repository directory" in GIT_CEILING_DIRECTORIES, so we should probably do the same here.

So how about this squashed into your patch?

On Sun, Mar 28, 2010 at 05:22:54AM -0400, Jeff King wrote:

Actually I take this back. It is in our CodingStyle guide, but we violate it all over the place (my grep counted 522). Perhaps it should be removed from CodingStyle.

-Peff

Jeff King <peff@peff.net> writes:

Yeah, looks nice; thanks both.

Thanks all for the suggestions! Jeff, shall I just squash in the doc patch you sent and resubmit the patches to the list?

-lars

-- lars r. damerow :: button pusher :: pixar animation studios

On Sun, Mar 28, 2010 at 10:32:25AM -0700, Lars Damerow wrote:

No need. Usually Junio's "thanks both" means he picked up the patches and squashed it himself, and indeed, it looks like he has your patches (with my doc change) in his 'pu' branch.

-Peff

On Sun, 28 Mar 2010, Junio C Hamano wrote:

I realize that I'm late to the party, but I do wonder if the "one filesystem" mode shouldn't be the default, rather than be enabled by a config option? IOW, just switch the meaning of the config option the other way.

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?

			Linus

Linus Torvalds wrote:

Not sure if I'm the only one, but I noticed at some point that mounting the t/ directory of git.git on tmpfs gives a huge speed boost to the test suite...

On Wed, Mar 31, 2010 at 12:59:33AM +0200, Thomas Rast wrote:

I noticed it, too, but my solution was a little different:

  $ git show f423ef5f
    tests: allow user to specify trash directory location

    The tests generate a large amount of I/O activity creating
    and destroying repositories and files. We can improve the
    time it takes to run the test suite by creating trash
    directories on filesystems with better performance
    characteristic, even though we may not want the rest of the
    git repository on those filesystems (e.g., because they are
    not network connected, or because they are temporary
    ramdisks).

    For example, on a dual processor system:

      $ cd t && time make -j32
      real    1m51.562s
      user    0m59.260s
      sys     1m20.933s

      # /dev/shm is tmpfs
      $ cd t && time make -j32 GIT_TEST_OPTS="--root=/dev/shm"
      real    1m1.484s
      user    0m53.555s
      sys     1m5.264s

-Peff

On Tue, Mar 30, 2010 at 03:43:01PM -0700, Linus Torvalds wrote:

Fashionably late, of course. I agree with your reasoning that it is a more sane default. The only thing that would make me hesitate on it now is that it is a behavior change. I suspect the group we would be breaking is small or even zero, though.

-Peff

Jeff King <peff@peff.net> writes:

Yeah, I think I agree with the reasoning, and it is not even _late_, as the feature hasn't escaped the lab yet.

On Tue, 30 Mar 2010, Jeff King wrote:

Well, I have to admit that I'm a _tiny_ bit nervous that some odd OS or filesystem has special magic st_dev rules so that it changes randomly even within a filesystem, but that would be very non-posix (think of the confusion it would cause standard UNIX tools like 'find -xdev' etc), so it's more a worry of "I have no idea what st_dev means on Windows" than anything really solid.

			Linus

On Wed, Mar 31, 2010 at 1:12 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

st_dev means "Drive number of the disk containing the file (same as st_rdev)."[1], and mounting file systems as subdirs of other file systems is rare (but possible) on Windows.

However, in our (f)stat implementation, st_dev means 0 -- but this might be possible to improve on.

[1]: http://msdn.microsoft.com/en-us/library/14h5k7ff(VS.71).aspx

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(-)

If a missing ONE_FILESYSTEM defaults to true, the only users who set this variable set it to false to tell git not to limit the discovery to one filesystem; there are too many negations in one sentence to make a simple panda brain dizzy.

Use the variable GIT_DISCOVERY_ACROSS_FILESYSTEM that changes the behaviour from the default "limit to one filesystem" to "cross the boundary as I ask you to"; makes the semantics much more straight forward.

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

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

Junio C Hamano <gitster@pobox.com> writes:

Right.

+	an explicit respository directory set via 'GIT_DIR' or on the

While you're there, you can spell respository as "repository" ;-).

I guess you still have one instance of GIT_ONE_FILESYSTEM a little below in the error message:

"Stopping at filesystem boundary since GIT_ONE_FILESYSTEM is true."

which should become

"Stopping at filesystem boundary since GIT_DISCOVERY_ACROSS_FILESYSTEM\n" "is not set."

or so.

Junio C Hamano <gitster@pobox.com> writes:

And this adds such a check.

 read-cache.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)