t1450: the order the objects are checked is undefined

When a tag T points at an object X that is of a type that is
different from what the tag records as, fsck should report it as an
error.

However, depending on the order X and T are checked individually,
the actual error message can be different.  If X is checked first,
fsck remembers X's type and then when it checks T, it notices that T
records X as a wrong type (i.e. the complaint is about a broken tag
T).  If T is checked first, on the other hand, fsck remembers that we
need to verify X is of the type tag records, and when it later
checks X, it notices that X is of a wrong type (i.e. the complaint
is about a broken object X).

The important thing is that fsck notices such an error and diagnoses
the issue on object X, but the test was expecting that we happen to
check objects in the order to make us detect issues with tag T, not
with object X.  Remove this unwarranted assumption.

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

fsck: --no-dangling omits "dangling object" information

The default output from "fsck" is often overwhelmed by informational
message on dangling objects, especially if you do not repack often, and a
real error can easily be buried.

Add "--no-dangling" option to omit them, and update the user manual to
demonstrate its use.

Based on a patch by Clemens Buchacher, but reverted the part to change
the default to --no-dangling, which is unsuitable for the first patch.
The usual three-step procedure to break the backward compatibility over
time needs to happen on top of this, if we were to go in that direction.

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

Update draft release notes to 1.7.10

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

Merge branch 'ld/git-p4-expanded-keywords'

* ld/git-p4-expanded-keywords:
  : Teach git-p4 to unexpand $RCS$-like keywords that are embedded in
  : tracked contents in order to reduce unnecessary merge conflicts.
  git-p4: add initial support for RCS keywords

Merge branch 'jk/config-include'

* jk/config-include:
  : An assignment to the include.path pseudo-variable causes the named file
  : to be included in-place when Git looks up configuration variables.
  config: add include directive
  config: eliminate config_exclusive_filename
  config: stop using config_exclusive_filename
  config: provide a version of git_config with more options
  config: teach git_config_rename_section a file argument
  config: teach git_config_set_multivar_in_file a default path
  config: copy the return value of prefix_filename
  t1300: add missing &&-chaining
  docs/api-config: minor clarifications
  docs: add a basic description of the config API

Merge branch 'jc/add-refresh-unmerged'

* jc/add-refresh-unmerged:
  refresh_index: do not show unmerged path that is outside pathspec

Merge branch 'js/configure-libintl'

* js/configure-libintl:
  configure: don't use -lintl when there is no gettext support

Merge branch 'pj/remote-set-branches-usage-fix'

* pj/remote-set-branches-usage-fix:
  remote: fix set-branches usage and documentation

Conflicts:
builtin/remote.c

Merge branch 'tr/perftest'

* tr/perftest:
  Add a performance test for git-grep
  Introduce a performance testing framework
  Move the user-facing test library to test-lib-functions.sh

Merge branch 'maint'

* maint:
  README: point to Documentation/SubmittingPatches
  Document merge.branchdesc configuration variable

git-p4: add initial support for RCS keywords

RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.

This change means that when git-p4 detects a problem applying
a patch, it will check to see if keyword expansion could be
the culprit. If it is, it strips the keywords in the p4
repository so that they match what git is expecting. It then
has another go at applying the patch.

This behaviour is enabled with a new git-p4 configuration
option and is off by default.

Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge: do not trust fstat(2) too much when checking interactiveness

The heuristic used by "git merge" to decide if it automatically gives an
editor upon clean automerge is to see if the standard input and the
standard output is the same device and is a tty, we are in an interactive
session.  "The same device" test was done by comparing fstat(2) result on
the two file descriptors (and they must match), and we asked isatty() only
for the standard input (we insist that they are the same device and there
is no point asking tty-ness of the standard output).

The stat(2) emulation in the Windows port however does not give a usable
value in the st_ino field, so even if the standard output is connected to
something different from the standard input, "The same device" test may
incorrectly return true. To accomodate it, add another isatty() check for
the standard output stream as well.

Reported-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

README: point to Documentation/SubmittingPatches

It was indeed not obvious for new contributors to find this document in
the source tree, since there were no reference to it outside the
Documentation/ directory.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document merge.branchdesc configuration variable

This was part of the "branch description" feature in the larger
"help people communicate better during their pull based workflow"
topic, but was never documented.

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

Sync with 1.7.9.2

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

Git 1.7.9.2

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

completion: use tabs for indentation

CodingGuidlines confidently declares "We use tabs for indentation."
It would be a shame if it were caught lying.

Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: remove stale "to submit patches" documentation

It was out-of-sync with the reality of who works on this
script. Defer (silently) to Documentation/SubmittingPatches
like all other code.

Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: the option to specify 'host' is -H, not -h

This was broken since the feature was introduced initially at abcaf07 (If
the user has configured various parameters, use them., 2008-08-10).

Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9100: remove bogus " || test" after each test scriptlet

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

Merge branch 'master' of git://bogomips.org/git-svn

* 'master' of git://bogomips.org/git-svn:
  git-svn.perl: fix a false-positive in the "already exists" test
  git-svn.perl: perform deletions before anything else
  git-svn: Fix time zone in --localtime
  git-svn: un-break "git svn rebase" when log.abbrevCommit=true
  git-svn: remove redundant porcelain option to rev-list
  completion: add --interactive option to git svn dcommit

Update draft release notes to 1.7.10

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

Merge branch 'jn/gitweb-unborn-head'

* jn/gitweb-unborn-head:
  gitweb: Fix "heads" view when there is no current branch

Merge branch 'jk/diff-highlight'

* jk/diff-highlight:
  diff-highlight: document some non-optimal cases
  diff-highlight: match multi-line hunks
  diff-highlight: refactor to prepare for multi-line hunks
  diff-highlight: don't highlight whole lines
  diff-highlight: make perl strict and warnings fatal

Merge branch 'maint'

* maint:
  Update draft release notes to 1.7.9.2
  completion: Allow dash as the first character for __git_ps1

Update draft release notes to 1.7.9.2

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

Merge branch 'cb/receive-pack-keep-errors' into maint

* cb/receive-pack-keep-errors:
  do not override receive-pack errors

Merge branch 'cb/transfer-no-progress' into maint

* cb/transfer-no-progress:
  push/fetch/clone --no-progress suppresses progress output

Merge branch 'jk/git-dir-lookup' into maint

* jk/git-dir-lookup:
  standardize and improve lookup rules for external local repos

Merge branch 'jc/diff-stat-scaler' into maint

* jc/diff-stat-scaler:
  diff --stat: show bars of same length for paths with same amount of changes

Merge branch 'zj/term-columns' into maint

* zj/term-columns:
  pager: find out the terminal width before spawning the pager

Merge branch 'cb/maint-rev-list-verify-object' into maint

* cb/maint-rev-list-verify-object:
  git rev-list: fix invalid typecast

Merge branch 'cb/maint-t5541-make-server-port-portable' into maint

* cb/maint-t5541-make-server-port-portable:
  t5541: check error message against the real port number used

Merge branch 'dp/i18n-libcharset' into maint

* dp/i18n-libcharset:
  Makefile: introduce CHARSET_LIB to link with -lcharset

Merge branch 'jk/grep-binary-attribute' into maint

* jk/grep-binary-attribute:
  grep: pre-load userdiff drivers when threaded
  grep: load file data after checking binary-ness
  grep: respect diff attributes for binary-ness
  grep: cache userdiff_driver in grep_source
  grep: drop grep_buffer's "name" parameter
  convert git-grep to use grep_source interface
  grep: refactor the concept of "grep source" into an object
  grep: move sha1-reading mutex into low-level code
  grep: make locking flag global

Merge branch 'nd/diffstat-gramnum' into maint

* nd/diffstat-gramnum:
  Use correct grammar in diffstat summary line

Merge branch 'nd/find-pack-entry-recent-cache-invalidation' into maint

* nd/find-pack-entry-recent-cache-invalidation:
  find_pack_entry(): do not keep packed_git pointer locally
  sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()

Merge branch 'tt/profile-build-fix' into maint

* tt/profile-build-fix:
  Makefile: fix syntax for older make
  Fix build problems related to profile-directed optimization

Merge branch 'fc/zsh-completion' into maint

* fc/zsh-completion:
  completion: simplify __gitcomp and __gitcomp_nl implementations
  completion: use ls -1 instead of rolling a loop to do that ourselves
  completion: work around zsh option propagation bug

git-svn.perl: fix a false-positive in the "already exists" test

open_or_add_dir checks to see if the directory already exists or not.
If it already exists and is not a directory, then we fail.  However,
open_or_add_dir did not previously account for the possibility that the
path did exist as a file, but is deleted in the current commit.

In order to prevent this legitimate case from failing, open_or_add_dir
needs to know what files are deleted in the current commit.
Unfortunately that information has to be plumbed through a couple of
layers.

Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn.perl: perform deletions before anything else

If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"

Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: Fix time zone in --localtime

Use numerical form of time zone to replace alphabetic time zone
abbreviation generated by "%Z". "%Z" is not portable and contain
ambiguity for many areas. For example, CST could be "Central
Standard Time" (GMT-0600) and "China Standard Time" (GMT+0800).
Alphabetic time zone abbreviation is meant for human readability,
not for specifying a time zone for machines.

Failed case can be illustrated like this in linux shell:
  > echo $TZ
  Asia/Taipei
  > date +%Z
  CST
  > env TZ=`date +%Z` date
  Mon Dec 19 06:03:04 CST 2011
  > date
  Mon Dec 19 14:03:04 CST 2011

[ew: fixed bad package reference inside Git::SVN::Log]

Signed-off-by: Wei-Yin Chen (陳威尹) <chen.weiyin@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: un-break "git svn rebase" when log.abbrevCommit=true

Change git-svn to use git-rev-list(1) instead of git-log(1) since the
latter is porcelain that'll cause "git svn rebase" to fail completely
if log.abbrevCommit is set to true in the configuration.

Without this patch the code will fail to parse a SHA1, and then just
spew a bunch of "Use of uninitialized value $hash in string eq"
warnings at "if ($c && $c eq $hash) { ..." and never do anything
useful.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: remove redundant porcelain option to rev-list

Change an invocation of git-rev-list(1) to not use --no-color,
git-rev-list(1) will always ignore that option and the --color option,
so there's no need to pass it.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

completion: add --interactive option to git svn dcommit

see afd7f1e for more details on git svn dcommit --interactive

Signed-off-by: Frederic Heitzmann <frederic.heitzmann@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

completion: Allow dash as the first character for __git_ps1

If the argument for `__git_ps1` begins with a dash, `printf` tries to
interpret it as an option which results in an error message.
The problem is solved by adding '--' before the argument to tell
`printf` to not interpret the following argument as an option.
Adding '--' directly to the argument does not help because the argument
is enclosed by double quotes.

Signed-off-by: Christian Hammerl <info@christian-hammerl.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes to 1.7.10

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

Merge branch 'tg/tag-points-at'

* tg/tag-points-at:
  builtin/tag.c: Fix a sparse warning
  tag: add --points-at list option

Merge branch 'jc/diff-stat-scaler'

* jc/diff-stat-scaler:
  diff --stat: show bars of same length for paths with same amount of changes

Merge branch 'zj/decimal-width'

* zj/decimal-width:
  make lineno_width() from blame reusable for others

Conflicts:
cache.h
pager.c

Merge branch 'zj/term-columns'

* zj/term-columns:
  pager: find out the terminal width before spawning the pager

Merge branch 'cb/transfer-no-progress'

* cb/transfer-no-progress:
  push/fetch/clone --no-progress suppresses progress output

Merge branch 'cb/receive-pack-keep-errors'

* cb/receive-pack-keep-errors:
  do not override receive-pack errors

Merge branch 'cb/maint-t5541-make-server-port-portable'

* cb/maint-t5541-make-server-port-portable:
  t5541: check error message against the real port number used

Merge branch 'cb/maint-rev-list-verify-object'

* cb/maint-rev-list-verify-object:
  git rev-list: fix invalid typecast

Merge branch 'maint'

* maint:
  Update draft release notes to 1.7.9.2
  gitweb: Fix 'grep' search for multiple matches in file

Update draft release notes to 1.7.9.2

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

configure: don't use -lintl when there is no gettext support

The current configure script uses -lintl if gettext is not found in the C
library, but does so before checking if there is libintl.h available in
the first place, in which case we would later define NO_GETTEXT.

Instead, check for the existence of libintl.h first. Only when libintl.h
exists and libintl is not in libc, ask for -lintl.

Signed-off-by: John Szakmeister <john@szakmeister.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: fix set-branches usage and documentation

The canonical order of command line arguments is always to have dashed
commands before other parameters, but the "git remote set-branches"
subcommand was described to take "name" before an optional "--add".

Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix 'grep' search for multiple matches in file

Commit ff7f218 (gitweb: Fix file links in "grep" search, 2012-01-05),
added $file_href variable, to reduce duplication and have the fix
applied in single place.

Unfortunately it made variable defined inside the loop, not taking into
account the fact that $file_href was set only if file changed.
Therefore for files with multiple matches $file_href was undefined for
second and subsequent matches.

Fix this bug by moving $file_href declaration outside loop.

Adds tests for almost all forms of sarch in gitweb, which were missing
from testuite.  Note that it only tests if there are no warnings, and
it doesn't check that gitweb finds what it should find.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refresh_index: do not show unmerged path that is outside pathspec

When running "git add --refresh <pathspec>", we incorrectly showed the
path that is unmerged even if it is outside the specified pathspec, even
though we did honor pathspec and refreshed only the paths that matched.

Note that this cange does not affect "git update-index --refresh"; for
hysterical raisins, it does not take a pathspec (it takes real paths) and
more importantly itss command line options are parsed and executed one by
one as they are encountered, so "git update-index --refresh foo" means
"first refresh the index, and then update the entry 'foo' by hashing the
contents in file 'foo'", not "refresh only entry 'foo'".

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

gitweb: Fix "heads" view when there is no current branch

In a repository whose HEAD points to an unborn branch with no commits,
"heads" view and "summary" view (which shows what is shown in "heads"
view) compared the object names of commits at the tip of branches with the
output from "git rev-parse HEAD", which caused comparison of a string with
undef and resulted in a warning in the server log.

This can happen if non-bare repository (with default 'master' branch)
is updated not via committing but by other means like push to it, or
Gerrit.  It can happen also just after running "git checkout --orphan
<new branch>" but before creating any new commit on this branch.

Rewrite the comparison so that it also works when $head points at nothing;
in such a case, no branch can be "the current branch", add a test for it.
While at it, rename local variable $head to $head_at, as it points to
current commit rather than current branch name (HEAD contents).

The code still incorrectly shows all branches that point at the same
commit as what HEAD points as "the current branch", even when HEAD is
detached. Fixing this bug is outside the scope of this patch.

Reported-by: Rajesh Boyapati
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add a performance test for git-grep

The only catch is that we don't really know what our repo contains, so
we have to ignore any possible "not found" status from git-grep.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Introduce a performance testing framework

This introduces a performance testing framework under t/perf/.  It
tries to be as close to the test-lib.sh infrastructure as possible,
and thus should be easy to get used to for git developers.

The following points were considered for the implementation:

1. You usually want to compare arbitrary revisions/build trees against
   each other.  They may not have the performance test under
   consideration, or even the perf-lib.sh infrastructure.

   To cope with this, the 'run' script lets you specify arbitrary
   build dirs and revisions.  It even automatically builds the revisions
   if it doesn't have them at hand yet.

2. Usually you would not want to run all tests.  It would take too
   long anyway.  The 'run' script lets you specify which tests to run;
   or you can also do it manually.  There is a Makefile for
   discoverability and 'make clean', but it is not meant for
   real-world use.

3. Creating test repos from scratch in every test is extremely
   time-consuming, and shipping or downloading such large/weird repos
   is out of the question.

   We leave this decision to the user.  Two different sizes of test
   repos can be configured, and the scripts just copy one or more of
   those (using hardlinks for the object store).  By default it tries
   to use the build tree's git.git repository.

   This is fairly fast and versatile.  Using a copy instead of a clone
   preserves many properties that the user may want to test for, such
   as lots of loose objects, unpacked refs, etc.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Move the user-facing test library to test-lib-functions.sh

This just moves all the user-facing functions to a separate file and
sources that instead.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: add include directive

It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).

This patch introduces an include directive for config files.
It looks like:

  [include]
    path = /path/to/file

This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).

The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.

Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:

  1. Parsing of other config-like files, like .gitmodules.
     There isn't a real need, and I'd rather be conservative
     and avoid unnecessary incompatibility or confusion.

  2. Reading single files via "git config". This is for two
     reasons:

       a. backwards compatibility with scripts looking at
          config-like files.

       b. inspection of a specific file probably means you
  care about just what's in that file, not a general
          lookup for "do we have this value anywhere at
  all". If that is not the case, the caller can
  always specify "--includes".

  3. Writing files via "git config"; we want to treat
     include.* variables as literal items to be copied (or
     modified), and not expand them. So "git config
     --unset-all foo.bar" would operate _only_ on
     .git/config, not any of its included files (just as it
     also does not operate on ~/.gitconfig).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: eliminate config_exclusive_filename

This is a magic global variable that was intended as an
override to the usual git-config lookup process. Once upon a
time, you could specify GIT_CONFIG to any git program, and
it would look only at that file. This turned out to be
confusing and cause a lot of bugs for little gain. As a
result, dc87183 (Only use GIT_CONFIG in "git config", not
other programs, 2008-06-30) took this away for all callers
except git-config.

Since git-config no longer uses it either, the variable can
just go away. As the diff shows, nobody was setting to
anything except NULL, so we can just replace any sites where
it was read with NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: stop using config_exclusive_filename

The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.

Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:

  1. A relative path specified by GIT_CONFIG=foo will look
     in the wrong directory if we have to chdir as part of
     repository setup. We already handle this properly for
     "git config -f foo", but the GIT_CONFIG lookup used
     config_exclusive_filename directly. By dropping to a
     single magic variable, the GIT_CONFIG case now just
     works.

  2. Calling "git config -f foo --edit" would not respect
     core.editor. This is because just before editing, we
     called git_config, which would respect the
     config_exclusive_filename setting, even though this
     particular git_config call was not about looking in the
     user's specified file, but rather about loading actual
     git config, just as any other git program would.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: provide a version of git_config with more options

Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable.  By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.

Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).

The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename.  That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: teach git_config_rename_section a file argument

The other config-writing functions (git_config_set and
git_config_set_multivar) each have an -"in_file" version to
write a specific file. Let's add one for rename_section,
with the eventual goal of moving away from the magic
config_exclusive_filename global.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: teach git_config_set_multivar_in_file a default path

The git_config_set_multivar_in_file function takes a
filename argument to specify the file into which the values
should be written. Currently, this value must be non-NULL.
Callers which want to write to the default location must use
the regular, non-"in_file" version, which will either write
to config_exclusive_filename, or to the repo config if the
exclusive filename is NULL.

Let's migrate the "default to using repo config" logic into
the "in_file" form. That will let callers get the same
default-if-NULL behavior as one gets with
config_exclusive_filename, but without having to use the
global variable.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: copy the return value of prefix_filename

The prefix_filename function returns a pointer to a static
buffer which may be overwritten by subsequent calls. Since
we are going to keep the result around for a while, let's be
sure to duplicate it for safety.

I don't think this can be triggered as a bug in the current
code, but it's a good idea to be defensive, as any resulting
bug would be quite subtle.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1300: add missing &&-chaining

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs/api-config: minor clarifications

The first change simply drops some parentheses to make a
statement more clear. The seconds clarifies that almost
nobody wants to call git_config_early.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with maint

Update draft release notes to 1.7.9.2

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

Merge branch 'jc/checkout-out-of-unborn' into maint

* jc/checkout-out-of-unborn:
  git checkout -b: allow switching out of an unborn branch

Merge branch 'jc/maint-mailmap-output' into maint

* jc/maint-mailmap-output:
  mailmap: always return a plain mail address from map_user()

Merge branch 'jk/prompt-fallback-to-tty' into maint

* jk/prompt-fallback-to-tty:
  prompt: fall back to terminal if askpass fails
  prompt: clean up strbuf usage

Merge branch 'jn/gitweb-search-utf-8' into maint

* jn/gitweb-search-utf-8:
  gitweb: Allow UTF-8 encoded CGI query parameters and path_info

Merge branch 'jc/maint-commit-ignore-i-t-a' into maint

* jc/maint-commit-ignore-i-t-a:
  commit: ignore intent-to-add entries instead of refusing

Conflicts:
cache-tree.c

Merge branch 'mm/empty-loose-error-message' into maint

* mm/empty-loose-error-message:
  fsck: give accurate error message on empty loose object files

Merge branch 'nk/ctype-for-perf' into maint

* nk/ctype-for-perf:
  ctype: implement islower/isupper macro
  ctype.c only wants git-compat-util.h

Merge branch 'jx/i18n-more-marking' into maint

* jx/i18n-more-marking:
  i18n: format_tracking_info "Your branch is behind" message
  i18n: git-commit whence_s "merge/cherry-pick" message

man: rearrange git synopsis to fit in 80 lines

The line was extended in 2dd8c3 ('git: add --info-path and --man-path
options'), and the formatted man output stopped fitting into the 80
column window.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: --list option for git-branch

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rt/completion-branch-edit-desc' into maint

* rt/completion-branch-edit-desc:
  completion: --edit-description option for git-branch

make lineno_width() from blame reusable for others

builtin/blame.c has a helper function to compute how many columns
we need to show a line-number, whose implementation is reusable as
a more generic helper function to count the number of columns
necessary to show any cardinal number.

Rename it to decimal_width(), move it to pager.c and export it for
use by future callers.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --stat: show bars of same length for paths with same amount of changes

When commit 3ed74e6 (diff --stat: ensure at least one '-' for deletions,
and one '+' for additions, 2006-09-28) improved the output for files with
tiny modifications, we accidentally broke the logic to ensure that two
equal sized changes are shown with the bars of the same length, even when
rounding errors exist.

Compute the length of the graph bars, using the same "non-zero changes is
shown with at least one column" scaling logic, but by scaling the sum of
additions and deletions to come up with the total length of the bar (this
ensures that two equal sized changes result in bars of the same length),
and then scaling the smaller of the additions or deletions. The other side
is computed as the difference between the two.

This makes the apportioning between additions and deletions less accurate
due to rounding errors, but it is much less noticeable than two files with
the same amount of change showing bars of different length.

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

Merge branch 'jk/git-dir-lookup'

* jk/git-dir-lookup:
  standardize and improve lookup rules for external local repos

Merge branch 'jk/grep-binary-attribute'

* jk/grep-binary-attribute:
  grep: pre-load userdiff drivers when threaded
  grep: load file data after checking binary-ness
  grep: respect diff attributes for binary-ness
  grep: cache userdiff_driver in grep_source
  grep: drop grep_buffer's "name" parameter
  convert git-grep to use grep_source interface
  grep: refactor the concept of "grep source" into an object
  grep: move sha1-reading mutex into low-level code
  grep: make locking flag global

Merge branch 'nd/pack-objects-parseopt'

* nd/pack-objects-parseopt:
  pack-objects: convert to use parse_options()
  pack-objects: remove bogus comment
  pack-objects: do not accept "--index-version=version,"

Merge branch 'dp/i18n-libcharset'

* dp/i18n-libcharset:
  Makefile: introduce CHARSET_LIB to link with -lcharset

Merge branch 'mh/war-on-extra-refs'

* mh/war-on-extra-refs:
  refs: remove the extra_refs API
  clone: do not add alternate references to extra_refs
  everything_local(): mark alternate refs as complete
  fetch-pack.c: inline insert_alternate_refs()
  fetch-pack.c: rename some parameters from "path" to "refname"
  clone.c: move more code into the "if (refs)" conditional
  t5700: document a failure of alternates to affect fetch

Merge branch 'lt/pull-no-edit'

* lt/pull-no-edit:
  "git pull" doesn't know "--edit"

Merge branch 'bl/gitweb-project-filter'

* bl/gitweb-project-filter:
  gitweb: Harden and improve $project_filter page title

Merge branch 'jn/ancient-meld-support'

* jn/ancient-meld-support:
  mergetools/meld: Use --help output to detect --output support

Merge branch 'jk/userdiff-config-simplify'

* jk/userdiff-config-simplify:
  drop odd return value semantics from userdiff_config

Sync with 1.7.9.1

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

Git 1.7.9.1

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