gc --aggressive: make --depth configurable

When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06)
made --depth=250 the default value, it didn't really explain the
reason behind, especially the pros and cons of --depth=250.

An old mail from Linus below explains it at length. Long story short,
--depth=250 is a disk saver and a performance killer. Not everybody
agrees on that aggressiveness. Let the user configure it.

    From: Linus Torvalds <torvalds@linux-foundation.org>
    Subject: Re: [PATCH] gc --aggressive: make it really aggressive
    Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST)
    Message-ID: <alpine.LFD.0.9999.0712060803430.13796@woody.linux-foundation.org>
    Gmane-URL: http://article.gmane.org/gmane.comp.gcc.devel/94637

    On Thu, 6 Dec 2007, Harvey Harrison wrote:
    >
    > 7:41:25elapsed 86%CPU

    Heh. And this is why you want to do it exactly *once*, and then just
    export the end result for others ;)

    > -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 pack-1d46...pack

    But yeah, especially if you allow longer delta chains, the end result can
    be much smaller (and what makes the one-time repack more expensive is the
    window size, not the delta chain - you could make the delta chains longer
    with no cost overhead at packing time)

    HOWEVER.

    The longer delta chains do make it potentially much more expensive to then
    use old history. So there's a trade-off. And quite frankly, a delta depth
    of 250 is likely going to cause overflows in the delta cache (which is
    only 256 entries in size *and* it's a hash, so it's going to start having
    hash conflicts long before hitting the 250 depth limit).

    So when I said "--depth=250 --window=250", I chose those numbers more as
    an example of extremely aggressive packing, and I'm not at all sure that
    the end result is necessarily wonderfully usable. It's going to save disk
    space (and network bandwidth - the delta's will be re-used for the network
    protocol too!), but there are definitely downsides too, and using long
    delta chains may simply not be worth it in practice.

    (And some of it might just want to have git tuning, ie if people think
    that long deltas are worth it, we could easily just expand on the delta
    hash, at the cost of some more memory used!)

    That said, the good news is that working with *new* history will not be
    affected negatively, and if you want to be _really_ sneaky, there are ways
    to say "create a pack that contains the history up to a version one year
    ago, and be very aggressive about those old versions that we still want to
    have around, but do a separate pack for newer stuff using less aggressive
    parameters"

    So this is something that can be tweaked, although we don't really have
    any really nice interfaces for stuff like that (ie the git delta cache
    size is hardcoded in the sources and cannot be set in the config file, and
    the "pack old history more aggressively" involves some manual scripting
    and knowing how "git pack-objects" works rather than any nice simple
    command line switch).

    So the thing to take away from this is:
     - git is certainly flexible as hell
     - .. but to get the full power you may need to tweak things
     - .. happily you really only need to have one person to do the tweaking,
       and the tweaked end results will be available to others that do not
       need to know/care.

    And whether the difference between 320MB and 500MB is worth any really
    involved tweaking (considering the potential downsides), I really don't
    know. Only testing will tell.

			    Linus

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
environment.c: fix constness for odb_pack_keep()

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-no-index: correctly diagnose error return from diff_opt_parse()

diff_opt_parse() returns the number of options parsed, or often
returns error() which is defined to return -1.  Yes, return value of
0 is "I did not process that option at all", which should cause the
caller to say that, but negative return should not be forgotten.

This bug caused "diff --no-index" to infinitely show the same error
message because the returned value was used to decrement the loop
control variable, e.g.

        $ git diff --no-index --color=words a b
        error: option `color' expects "always", "auto", or "never"
        error: option `color' expects "always", "auto", or "never"
        ...

Instead, make it act like so:

        $ git diff --no-index --color=words a b
        error: option `color' expects "always", "auto", or "never"
        fatal: invalid diff option/value: --color=words

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dir.c: make git_fnmatch() not inline

Now that it calls a static inline function, it cannot be an inline
definition with external linkage. Remove inline and make it an
external definition.

Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: don't rely on strerror text when testing rmdir failure

AIX doesn't make a distiction between EEXIST and ENOTEMPTY; relying
on the strerror string for the rmdir failure is fragile. Just test
that the start of the string matches the Git controlled "failed to
rmdir..."  error. The exact text of the OS generated error string
isn't important to the test.

Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse: fix typo in example on manpage

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'ib/rev-parse-parseopt-argh' into next

Teaches the "rev-parse --parseopt" mechanism used by scripted
Porcelains to parse command line options and give help text how to
supply argv-help (the placeholder string for an option parameter,
e.g. "key-id" in "--gpg-sign=<key-id>").

* ib/rev-parse-parseopt-argh:
  rev-parse: fix typo in example on manpage
Merge branch 'cb/aix' into next

* cb/aix:
  tests: don't rely on strerror text when testing rmdir failure
  dir.c: make git_fnmatch() not inline
Merge branch 'jc/fix-diff-no-index-diff-opt-parse' into next

"diff --no-index -Mq a b" fell into an infinite loop.

* jc/fix-diff-no-index-diff-opt-parse:
  diff-no-index: correctly diagnose error return from diff_opt_parse()
Merge branch 'nd/gc-aggressive' into next

Allow tweaking the maximum length of the delta-chain produced by
"gc --aggressive".

* nd/gc-aggressive:
  environment.c: fix constness for odb_pack_keep()
  gc --aggressive: make --depth configurable
builtin/show: do not prune by pathspec

By design, "git show commit -- path" is not "git show commit:path", and
there is no reason to change that. But "git show commit -- path" simply
returns nothing at all "most of the time" because it prunes by pathspec
even though it does not walk commits. This is pretty useless.

So, turn off commit pruning (but keep diff limiting of course) so that
"git show commit -- path" shows the commit message and the diff that the
commit introduces to path (filtered by path); only the diff will be
empty "most of the time".

As an intended side effect, users mistaking "git show commit -- path"
for "git show commit:path" are automatically reminded that they asked
git to show a commit, not a blob.

In case the user has specified "--do-walk", assume they want the old
behaviour (prune by default).

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>