When overriding the identifier "stat" so that "struct stat" will be
substituted with "struct _stati64" everywhere, I tried to fix the calls
to the _function_ stat(), too, but I forgot to change the earlier
attempt "stat64" to "_stati64" there.

So, the stat() calls were overridden by calls to _stati64() instead.

Unfortunately, there is a function _stati64() so that I missed that
calls to stat() were not actually overridden by calls to mingw_lstat(),
but t4200-rerere.sh showed the error.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* en/maint-hash-object:
  Ensure proper setup of git_dir for git-hash-object

Conflicts:
	hash-object.c

* jc/blame:
  blame: show "previous" information in --porcelain/--incremental format
  git-blame: refactor code to emit "porcelain format" output

* ns/pretty-format:
  bash completion: add --format= and --oneline options for "git log"
  Add tests for git log --pretty, --format and --oneline.
  Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"
  Give short-hands to --pretty=tformat:%formatstring
  Add --format that is a synonym to --pretty

* jk/sane-relative-time:
  never fallback relative times to absolute

* fc/config-editor:
  git config: trivial cleanup for editor action
  git config: codestyle cleanups
  config: Add new option to open an editor.

* js/send-email:
  send-email: add --confirm option and configuration setting
  send-email: don't create temporary compose file until it is needed
  send-email: --suppress-cc improvements
  send-email: handle multiple Cc addresses when reading mbox message
  send-email: allow send-email to run outside a repo

* sg/rerere-cleanup:
  rerere: remove duplicated functions

* jc/add-p-unquote:
  git-add -i/-p: learn to unwrap C-quoted paths

* jw/imap-preformatted-html:
  imap.preformattedHTML to tell Thunderbird to send non-flowed text

* jw/format-patch-attach:
  Enable setting attach as the default in .gitconfig for git-format-patch.

* sr/force-rebase:
  Teach rebase to rebase even if upstream is up to date

* fg/exclude-bq:
  Support "\" in non-wildcard exclusion entries

* dm/add-i-edit-abort:
  add -i: revisit hunk on editor failure

* tp/completion:
  Fixup: Add bare repository indicator for __git_ps1
  Add bare repository indicator for __git_ps1
  completion: More fixes to prevent unbound variable errors
  completion: Better __git_ps1 support when not in working directory
  completion: Use consistent if [...] convention, not "test"
  completion: For consistency, change "git rev-parse" to __gitdir calls

* js/branch-symref:
  add basic branch display tests
  branch: clean up repeated strlen
  Avoid segfault with 'git branch' when the HEAD is detached
  builtin-branch: improve output when displaying remote branches

Conflicts:
	builtin-branch.c

* al/ansi-color:
  builtin-branch.c: Rename branch category color names
  Clean up use of ANSI color sequences

* js/valgrind:
  valgrind: do not require valgrind 3.4.0 or newer
  test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
  Tests: let --valgrind imply --verbose and --tee
  Add a script to coalesce the valgrind outputs
  t/Makefile: provide a 'valgrind' target
  test-lib.sh: optionally output to test-results/$TEST.out, too
  Valgrind support: check for more than just programming errors
  valgrind: ignore ldso and more libz errors
  Add valgrind support in test scripts

The type 'off_t' should be used everywhere so that the bit-depth of that
type can be adjusted in the standard C library, and you just need to
recompile your program to benefit from the extended precision.

Only that it was not done that way in the MS runtime library.

This patch reroutes off_t to off64_t and provides the other necessary
changes so that finally, clones larger than 2 gigabyte work on Windows
(provided you are on a file system that allows files larger than 2gb).

Initial patch by Sickboy <sb@dev-heaven.net>.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Including passing parameters to the programs, and running more
complicated checks without requiring a seperate shell script.
Signed-off-by: NJohn Tapsell <johnflux@gmail.com>
Acked-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* maint:
  Make the 'lock file' exists error more informative

Certain remote commands, when asked to do something in a
particular directory that was not actually a git repository,
would say "unable to chdir or not a git archive". The
"chdir" bit is an unnecessary detail, and the term "git
archive" is much less common these days than "git repository".

So let's switch them all to:

  fatal: '%s' does not appear to be a git repository
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It looks like someone did 90% of the work, then forgot to actually use
the function in one place.

Also the helper function did not use the correct variable.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When archiving a repository there is no way to specify a file as output.
This patch adds a new option "--output" that redirects the output to a
file instead of stdout.
Signed-off-by: NCarlos Manuel Duclos Vergara <carlos.duclos@nokia.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Tell the user that a backup (original) already exists, and how to solve
this problem (with -f option)
Signed-off-by: NJohn Tapsell <johnflux@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Also add a comment that the web interface wraps the lines
Signed-off-by: NJohn Tapsell <johnflux@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A lot of people see this message for the first time on the gitweb
interface, where there is no clue as to what 'this file' means.
Signed-off-by: NJohn Tapsell <johnflux@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This patch teaches "git rev-list --bisect-vars" to output an estimate
of the number of bisection step left _after the current one_ along with
the other variables it already outputs.

This patch also makes "git-bisect.sh" display this number of steps left
_after the current one_, along with the estimate of the number of
revisions left to test (after the current one).

Here is a table to help analyse what should be the best estimate for
the number of bisect steps left.

N : linear case                    --> probabilities --> best
-------------------------------------------------------------
1 : G-B                            --> 0             --> 0
2 : G-U1-B                         --> 0             --> 0
3 : G-U1-U2-B                      --> 0(1/3) 1(2/3) --> 1
4 : G-U1-U2-U3-B                   --> 1             --> 1
5 : G-U1-U2-U3-U4-B                --> 1(3/5) 2(2/5) --> 1
6 : G-U1-U2-U3-U4-U5-B             --> 1(2/6) 2(4/6) --> 2
7 : G-U1-U2-U3-U4-U5-U6-B          --> 1(1/7) 2(6/7) --> 2
8 : G-U1-U2-U3-U4-U5-U6-U7-B       --> 2             --> 2
9 : G-U1-U2-U3-U4-U5-U6-U7-U8-B    --> 2(7/9) 3(2/9) --> 2
10: G-U1-U2-U3-U4-U5-U6-U7-U8-U9-B --> 2(6/10)3(4/10)--> 2

In the column "N", there is the number of revisions that could _now_
be the first bad commit we are looking for.

The "linear case" column describes the linear history corresponding to
the number in column N. G means good, B means bad, and Ux means
unknown. Note that the first bad revision we are looking for can be
any Ux or B.

In the "probabilities" column, there are the different outcomes in
number of steps with the odds of each outcome in parenthesis
corresponding to the linear case.

The "best" column gives the most accurate estimate among the different
outcomes in the "probabilities" column.

We have the following:

best(2^n) == n - 1

and for any x between 0 included and 2^n excluded, the probability for
n - 1 steps left looks like:

P(2^n + x) == (2^n - x) / (2^n + x)

and P(2^n + x) < 0.5 means 2^n < 3x

So the algorithm used in this patch calculates 2^n and x, and then
choose between returning n - 1 and n.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Code that calls diff_setup(), including via init_revisions(), should later call
diff_setup_done(), possibly via setup_revisions(). Failure to do so could cause
errors, especially in the future when we add responsibilities to
diff_setup_done(). This instance causes no known errors with the present code.
But it resulted in an error with an experimental patch.
Signed-off-by: NKeith Cascio <keith@cs.ucla.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NKeith Cascio <keith@cs.ucla.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

Signed-off-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These may not be obvious to non-native English speakers
Signed-off-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NRoy Lee <roylee17@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

send-email violates the principle of least surprise by automatically
cc'ing additional recipients without confirming this with the user.

This patch teaches send-email a --confirm option. It takes the
following values:

 --confirm=always   always confirm before sending
 --confirm=never    never confirm before sending
 --confirm=cc       confirm before sending when send-email has
                    automatically added addresses from the patch to
                    the Cc list
 --confirm=compose  confirm before sending the first message when
                    using --compose. (Needed to maintain backwards
                    compatibility with existing behavior.)
 --confirm=auto     'cc' + 'compose'

If sendemail.confirm is unconfigured, the option defaults to 'compose'
if any suppress-Cc related options have been used, otherwise it defaults
to 'auto'.

Unfortunately, it is impossible to introduce this patch such that it
helps new users without potentially annoying some existing users. We
attempt to mitigate the latter by:

 * Allowing the user to set 'git config sendemail.confirm never'
 * Allowing the user to say 'all' after the first prompt to not be
   prompted on remaining emails during the same invocation.
 * Telling the user about the 'sendemail.confirm' setting if it is
   unconfigured whenever we prompt due to Cc before sending.
 * Only prompting if no --suppress related options have been passed, as
   using such an option is likely to indicate an experienced send-email
   user.

There is a slight fib in message informing the user of the
sendemail.confirm setting and this is intentional. Setting 'auto'
differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
obviously squelches the informational message; 2) 'auto' prompts when
the Cc list has been expanded even in the presence of a --suppress
related option, where leaving sendemail.confirm unset does not. This is
intentional to keep the message simple, and to avoid adding another
sendemail.confirm value ('auto-except-suppress'?).
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>