Merge branch 'pw/completion-stash'

* pw/completion-stash:
completion: update completion arguments for stash

Merge branch 'pw/completion-show-branch'

* pw/completion-show-branch:
completion: complete show-branch "--date-order"

Merge branch 'jk/completion-rebase'

* jk/completion-rebase:
completion: add missing git-rebase options

Merge branch 'nd/diff-with-path-params'

A few options of "git diff" did not work well when the command was
run from a subdirectory.

* nd/diff-with-path-params:
diff: make -O and --output work in subdirectory
diff-no-index: do not take a redundant prefix argument

Merge branch 'lv/add-doc-working-tree'

* lv/add-doc-working-tree:
git-add doc: do not say working directory when you mean working tree

Merge branch 'dw/subtree-split-do-not-drop-merge'

The "split" subcommand of "git subtree" (in contrib/) incorrectly
skipped merges when it shouldn't, which was corrected.

* dw/subtree-split-do-not-drop-merge:
contrib/subtree: fix "subtree split" skipped-merge bug

Merge branch 'tb/complete-word-diff-regex'

* tb/complete-word-diff-regex:
completion: complete "diff --word-diff-regex="

Merge branch 'mk/asciidoctor-bq-workaround'

* mk/asciidoctor-bq-workaround:
Documentation: remove unnecessary backslashes

Merge branch 'dg/subtree-test'

* dg/subtree-test:
contrib/subtree: Make testing easier

Merge branch 'tg/ls-remote-symref'

"ls-remote" learned an option to show which branch the remote
repository advertises as its primary by pointing its HEAD at.

* tg/ls-remote-symref:
ls-remote: add support for showing symrefs
ls-remote: use parse-options api
ls-remote: fix synopsis
ls-remote: document --refs option
ls-remote: document --quiet option

Merge branch 'tb/ls-files-eol'

"git ls-files" learned a new "--eol" option to help diagnose
end-of-line problems.

* tb/ls-files-eol:
ls-files: add eol diagnostics

Merge branch 'jk/notes-merge-from-anywhere'

"git notes merge" used to limit the source of the merged notes tree
to somewhere under refs/notes/ hierarchy, which was too limiting
when inventing a workflow to exchange notes with remote
repositories using remote-tracking notes trees (located in e.g.
refs/remote-notes/ or somesuch).

* jk/notes-merge-from-anywhere:
notes: allow merging from arbitrary references

Merge branch 'jc/peace-with-crlf'

Many commands that read files that are expected to contain text
that is generated (or can be edited) by the end user to control
their behaviour (e.g. "git grep -f <filename>") have been updated
to be more tolerant to lines that are terminated with CRLF (they
used to treat such a line to contain payload that ends with CR,
which is usually not what the users expect).

* jc/peace-with-crlf:
test-sha1-array: read command stream with strbuf_getline()
grep: read -f file with strbuf_getline()
send-pack: read list of refs with strbuf_getline()
column: read lines with strbuf_getline()
cat-file: read batch stream with strbuf_getline()
transport-helper: read helper response with strbuf_getline()
clone/sha1_file: read info/alternates with strbuf_getline()
remote.c: read $GIT_DIR/remotes/* with strbuf_getline()
ident.c: read /etc/mailname with strbuf_getline()
rev-parse: read parseopt spec with strbuf_getline()
revision: read --stdin with strbuf_getline()
hash-object: read --stdin-paths with strbuf_getline()

restore_env(): free the saved environment variable once we are done

Just like we free orig_cwd, which is the value of the original
working directory saved in save_env_before_alias(), once we are
done with it, the contents of orig_env[] array, saved in the
save_env_before_alias() function should be freed; otherwise,
the second and subsequent calls to save/restore pair will leak
the memory allocated in save_env_before_alias().

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

test-lib: limit the output of the yes utility

On Windows, there is no SIGPIPE. A consequence of this is that the
upstream process of a pipe does not notice the death of the downstream
process until the pipe buffer is full and writing more data returns an
error. This behavior is the reason for an annoying delay during the
execution of t7610-mergetool.sh: There are a number of test cases where
'yes' is invoked upstream. Since the utility is basically an endless
loop it runs, on Windows, until the pipe buffer is full. This does take
a few seconds.

The test suite has its own implementation of 'yes'. Modify it to produce
only a limited amount of output that is sufficient for the test suite.
The amount chosen should be sufficiently high for any test case, assuming
that future test cases will not exaggerate their demands of input from
an upstream 'yes' invocation.

[j6t: commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Getting closer to 2.7.1

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

Merge branch 'jk/list-tag-2.7-regression'

"git tag" started listing a tag "foo" as "tags/foo" when a branch
named "foo" exists in the same repository; remove this unnecessary
disambiguation, which is a regression introduced in v2.7.0.

* jk/list-tag-2.7-regression:
tag: do not show ambiguous tag names as "tags/foo"
t6300: use test_atom for some un-modern tests

Merge branch 'ew/svn-1.9.0-auth'

* ew/svn-1.9.0-auth:
git-svn: fix auth parameter handling on SVN 1.9.0+

push: fix ref status reporting for --force-with-lease

The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.

Modify the --force-with-lease ref status logic to leverage
the --force ref status logic when the "lease" conditions
are met.

Also, enhance tests to validate output status reporting.

Signed-off-by: Andrew Wheeler <awheeler@motorola.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply, ls-files: simplify "-z" parsing

As a short option, we cannot handle negation. Thus a callback
handling "unset" is overkill, and we can just use OPT_SET_INT
instead to handle setting the option.

Anybody who adds "--nul" synonym to this later would need to be
careful not to break "--no-nul", which should mean that lines are
terminated with LF at the end.

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

checkout-index: disallow "--no-stage" option

We do not really expect people to use "--no-stage", but if
they do, git currently segfaults. We could instead have it
undo the effects of a previous "--stage", but this gets
tricky around the "to_tempfile" flag. We cannot simply reset
it to 0, because we don't know if it was set by a previous
"--stage=all" or an explicit "--temp" option.

We could solve this by setting a flag and resolving
to_tempfile later, but it's not worth the effort. Nobody
actually wants to use "--no-stage"; we are just trying to
fix a potential segfault here.

While we're in the area, let's improve the user-facing
messages for this option. The error string should be
translatable, and we should give some hint in the "-h"
output about what can go in the argument field.

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

checkout-index: handle "--no-index" option

The parsing of "--index" is done in a callback, but it does
not handle an "unset" option. We don't necessarily expect
anyone to use this, but the current behavior is to treat it
exactly like "--index", which would probably be surprising.

Instead, let's just turn it into an OPT_BOOL, and handle it
after we're done parsing. This makes "--no-index" just work
(it cancels a previous "--index").

As a bonus, this makes the logic easier to follow. The old
code opened the index during the option parsing, leaving the
reader to wonder if there was some timing issue (there
isn't; none of the other options care that we've opened it).
And then if we found that "--prefix" had been given, we had
to rollback the index. Now we can simply avoid opening it in
the first place.

Note that it might make more sense for checkout-index to
complain when "--index --prefix=foo" is given (rather than
silently ignoring "--index"), but since it has been that way
since 415e96c ([PATCH] Implement git-checkout-cache -u to
update stat information in the cache., 2005-05-15), it's
safer to leave it as-is.

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

checkout-index: handle "--no-prefix" option

We use a custom callback to parse "--prefix", but it does
not handle the "unset" case. As a result, passing
"--no-prefix" will cause a segfault.

We can fix this by switching it to an OPT_STRING, which
makes "--no-prefix" counteract a previous "--prefix". Note
that this assigns NULL, so we bump our default-case
initialization to lower in the main function.

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

checkout-index: simplify "-z" option parsing

Now that we act as a simple bool, there's no need to use a
custom callback.

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

give "nbuf" strbuf a more meaningful name

It's a common pattern in our code to read paths from stdin,
separated either by newlines or NULs, and unquote as
necessary. In each of these five cases we use "nbuf" to
temporarily store the unquoted value. Let's give it the more
meaningful name "unquoted", which makes it easier to
understand the purpose of the variable.

While we're at it, let's also static-initialize all of our
strbufs. It's not wrong to call strbuf_init, but it
increases the cognitive load on the reader, who might wonder
"do we sometimes avoid initializing them? why?".

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

object name: introduce '^{/!-<negative pattern>}' notation

To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say

$ git rev-parse HEAD^{/!-foo}

and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.

The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:

$ git diff @^{/!-^WIP}

The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.

Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

transport: drop support for git-over-rsync

The git-over-rsync protocol is inefficient and broken, and
has been for a long time. It transfers way more objects than
it needs (grabbing all of the remote's "objects/",
regardless of which objects we need). It does its own ad-hoc
parsing of loose and packed refs from the remote, but
doesn't properly override packed refs with loose ones,
leading to garbage results (e.g., expecting the other side
to have an object pointed to by a stale packed-refs entry,
or complaining that the other side has two copies of the
refs[1]).

This latter breakage means that nobody could have
successfully pulled from a moderately active repository
since cd547b4 (fetch/push: readd rsync support, 2007-10-01).

We never made an official deprecation notice in the release
notes for git's rsync protocol, but the tutorial has marked
it as such since 914328a (Update tutorial., 2005-08-30).
And on the mailing list as far back as Oct 2005, we can find
Junio mentioning it as having "been deprecated for quite
some time."[2,3,4]. So it was old news then; cogito had
deprecated the transport in July of 2005[5] (though it did
come back briefly when Linus broke git-http-pull!).

Of course some people professed their love of rsync through
2006, but Linus clarified in his usual gentle manner[6]:

> Thanks! This is why I still use rsync, even though
> everybody and their mother tells me "Linus says rsync is
> deprecated."

No. You're using rsync because you're actively doing
something _wrong_.

The deprecation sentiment was reinforced in 2008, with a
mention that cloning via rsync is broken (with no fix)[7].

Even the commit porting rsync over to C from shell (cd547b4)
lists it as deprecated! So between the 10 years of informal
warnings, and the fact that it has been severely broken
since 2007, it's probably safe to simply remove it without
further deprecation warnings.

[1] http://article.gmane.org/gmane.comp.version-control.git/285101
[2] http://article.gmane.org/gmane.comp.version-control.git/10093
[3] http://article.gmane.org/gmane.comp.version-control.git/17734
[4] http://article.gmane.org/gmane.comp.version-control.git/18911
[5] http://article.gmane.org/gmane.comp.version-control.git/5617
[6] http://article.gmane.org/gmane.comp.version-control.git/19354
[7] http://article.gmane.org/gmane.comp.version-control.git/103635

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

stripspace: call U+0020 a "space" instead of a "blank"

I couldn't find any other examples of people referring to this
character as a "blank".

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

convert: treat an empty string for clean/smudge filters as "cat"

Once a lower-priority configuration file defines a clean or smudge
filter, there is no convenient way to override it to produce as-is
output. Even though the configuration mechanism implements "the
last one wins" semantics, you cannot set them to an empty string and
expect them to work, as apply_filter() would try to run the empty
string as an external command and fail. The conversion is not done,
but the function would still report a failure to convert.

Even though resetting the variable to "cat" (i.e. pass the data back
as-is and report success) is an obvious and a viable way to solve
this, it is wasteful to spawn an external process just as a
workaround.

Instead, teach apply_filter() to treat an empty string as a no-op
filter that always returns successfully its input as-is without
conversion.

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fourth batch for 2.8.cycle

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

Merge branch 'jk/shortlog'

"git shortlog" used to accumulate various pieces of information
regardless of what was asked to be shown in the final output. It
has been optimized by noticing what need not to be collected
(e.g. there is no need to collect the log messages when showing
only the number of changes).

* jk/shortlog:
shortlog: don't warn on empty author
shortlog: optimize out useless string list
shortlog: optimize out useless "<none>" normalization
shortlog: optimize "--summary" mode
shortlog: replace hand-parsing of author with pretty-printer
shortlog: use strbufs to read from stdin
shortlog: match both "Author:" and "author" on stdin

Merge branch 'jc/strbuf-getline'

The preliminary clean-up for jc/peace-with-crlf topic.

* jc/strbuf-getline:
strbuf: give strbuf_getline() to the "most text friendly" variant
checkout-index: there are only two possible line terminations
update-index: there are only two possible line terminations
check-ignore: there are only two possible line terminations
check-attr: there are only two possible line terminations
mktree: there are only two possible line terminations
strbuf: introduce strbuf_getline_{lf,nul}()
strbuf: make strbuf_getline_crlf() global
strbuf: miniscule style fix

Merge branch 'js/msys2'

Beginning of the upstreaming process of Git for Windows effort.

* js/msys2:
mingw: uglify (a, 0) definitions to shut up warnings
mingw: squash another warning about a cast
mingw: avoid warnings when casting HANDLEs to int
mingw: avoid redefining S_* constants
compat/winansi: support compiling with MSys2
compat/mingw: support MSys2-based MinGW build
nedmalloc: allow compiling with MSys2's compiler
config.mak.uname: supporting 64-bit MSys2
config.mak.uname: support MSys2

Merge branch 'tk/interpret-trailers-in-place'

"interpret-trailers" has been taught to optionally update a file in
place, instead of always writing the result to the standard output.

* tk/interpret-trailers-in-place:
interpret-trailers: add option for in-place editing
trailer: allow to write to files other than stdout

Merge branch 'jk/sanity'

The description for SANITY prerequisite the test suite uses has
been clarified both in the comment and in the implementation.

* jk/sanity:
test-lib: clarify and tighten SANITY

Merge branch 'jk/filter-branch-no-index'

A recent optimization to filter-branch in v2.7.0 introduced a
regression when --prune-empty filter is used, which has been
corrected.

* jk/filter-branch-no-index:
filter-branch: resolve $commit^{tree} in no-index case

pass transport verbosity down to git_connect

While working in connect.c to perform non-blocking connections,
I noticed calling "git fetch -v" was not causing the progress
messages inside git_tcp_connect_sock to be emitted as I
expected.

Looking at history, it seems connect_setup has never been called
with the verbose parameter. Since transport already has a
"verbose" field, use that field instead of another parameter
in connect_setup.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: do not bother to test funny file names

MSYS2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSYS2 bash to run the tests, such files or
directories are created successfully, but Git itself has no chance to
work with them because it is a regular Windows program, hence limited by
the Win32 API.

With this change, on Windows otherwise failing tests in
t3300-funny-names.sh, t3600-rm.sh, t3703-add-magic-pathspec.sh,
t3902-quoted.sh, t4016-diff-quote.sh, t4135-apply-weird-filenames.sh,
t9200-git-cvsexportcommit.sh, and t9903-bash-prompt.sh are skipped.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: skip a test in t9130 that cannot pass on Windows

On Windows, Git itself has no clue about POSIX paths, but its shell
scripts do. In this instance, we get mixed paths as a result, and when
comparing the path of the author file, we get a mismatch that is
entirely due to the POSIX path vs Windows path clash.

Let's just skip this test so that t9130-git-svn-authors-file.sh passes
in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: handle the missing POSIXPERM prereq in t9124

On Windows, the permission system works completely differently than
expected by some of the tests. So let's make sure that we do not test
POSIX functionality on Windows.

This lets t9124-git-svn-dcommit-auto-props.sh pass in Git for Windows'
SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: avoid illegal filename in t9118

On Windows' file systems, file names with trailing dots are forbidden.
The POSIX emulation layer used by Git for Windows' Subversion emulates
those file names, therefore the test adding the file would actually
succeed, but when we would ask git.exe (which does not leverage the
POSIX emulation layer) to check out the tree, it would fail.

Let's just guard the test using a filename that is illegal on Windows
by the MINGW prereq.

This lets t9118-git-svn-funky-branch-names.sh pass in Git for Windows'
SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: mark t9100's test cases with appropriate prereqs

Many a test requires either POSIXPERM (to change the executable bit) or
SYMLINKS, and neither are available on Windows.

This lets t9100-git-svn-basic.sh pass in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0008: avoid absolute path

The colon is used by check-ignore to separate paths from other output
values. If we use an absolute path, however, on Windows it will be
converted into a Windows path that very much contains a colon.

It is actually not at all necessary to make the path of the global
excludes absolute, so let's just not even do that.

Based on suggestions by Karsten Blees and Junio Hamano.

Suggested-by: Karsten Blees <karsten.blees@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: work around pwd issues in the tests

In Git for Windows' SDK, the tests are run using a Bash that relies on
the POSIX emulation layer MSYS2 (itself a friendly fork of Cygwin). As
such, paths in tests can be POSIX paths. As soon as those paths are
passed to git.exe (which does *not* use the POSIX emulation layer),
those paths are converted into Windows paths, though. This happens
for command-line parameters, but not when reading, say, config variables.

To help with that, the `pwd` command is overridden to return the Windows
path of the current working directory when testing Git on Windows.

However, when talking to anything using the POSIX emulation layer, it is
really much better to use POSIX paths because Windows paths contain a
colon after the drive letter that will easily be mistaken for the common
separator in path lists.

So let's just use the $PWD variable when the POSIX path is needed.

This lets t7800-difftool.sh, t9400-git-cvsserver-server.sh,
t9402-git-cvsserver-refs.sh and t9401-git-cvsserver-crlf.sh pass in Git
for Windows' SDK.

Note: the cvsserver tests require not only the `cvs` package (install
it into Git for Windows' SDK via `pacman -S cvs`) but also the Perl
SQLite bindings (install them into Git for Windows' SDK via
`cpan DBD::SQLite`).

This patch is based on earlier work by 마누엘 and Karsten Blees.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: fix t9700's assumption about directory separators

This test assumed that there is only one directory separator (the
forward slash), not two equivalent directory separators.
However, on Windows, the back slash and the forward slash *are*
equivalent.

Let's paper over this issue by converting the backward slashes to
forward ones in the test that fails with MSYS2 otherwise.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: skip test in t1508 that fails due to path conversion

In Git for Windows, the MSYS2 POSIX emulation layer used by the Bash
converts command-line arguments that looks like they refer to a POSIX
path containing a file list (i.e. @<absolute-path>) into a Windows path
equivalent when calling non-MSYS2 executables, such as git.exe.

Let's just skip the test that uses the parameter `@/at-test` that
confuses the MSYS2 runtime.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: turn off git-daemon tests if FIFOs are not available

The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.

This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that POSIX emulation layer and therefore blinks twice when it sees
MSYS2's emulated FIFOs and then just stares into space.

This lets t5570-git-daemon.sh and t5811-proto-disable-git.sh pass.

Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git: simplify environment save/restore logic

The only code that cares about the value of the global variable
saved_env_before_alias after the previous fix is handle_builtin()
that turns into a glorified no-op when the variable is true, so the
logic could safely be lifted to its caller, i.e. the caller can
refrain from calling it when the variable is set.

This variable tells us if save_env_before_alias() was called (with
or without matching restore_env()), but the sole caller of the
function, handle_alias(), always calls it as the first thing, so we
can consider that the variable essentially keeps track of the fact
that handle_alias() has ever been called.

It turns out that handle_builtin() and handle_alias() are called
only from one function in a way that the value of the variable
matters, which is run_argv(), and it already keeps track of the
fact that it already called handle_alias().

So we can simplify the whole thing by:

- Change handle_builtin() to always make a direct call to the
builtin implementation it finds, and make sure the caller
refrains from calling it if handle_alias() has ever been
called;

- Remove saved_env_before_alias variable, and instead use the
local "done_alias" variable maintained inside run_argv() to
make the same decision.

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

git: protect against unbalanced calls to {save,restore}_env()

We made sure that save_env_before_alias() does not skip saving the
environment when asked to (which led to use-after-free of orig_cwd
in restore_env() in the buggy version) with the previous step.

Protect against future breakage where somebody adds new callers of
these functions in an unbalanced fashion.

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

git: remove an early return from save_env_before_alias()

When help.autocorrect is in effect, an attempt to auto-execute an
uniquely corrected result of a misspelt alias will result in an
irrelevant error message. The codepath that causes this calls
save_env_before_alias() and restore_env() in handle_alias(), and
that happens twice. A global variable orig_cwd is allocated to hold
the return value of getcwd() in save_env_before_alias(), which is
then used in restore_env() to go back to that directory and finally
free(3)'d there.

However, save_env_before_alias() is not prepared to be called twice.
It returns early when it knows it has already been called, leaving
orig_cwd undefined, which is then checked in the second call to
restore_env(), and by that time, the memory that used to hold the
contents of orig_cwd is either freed or reused to hold something
else, and this is fed to chdir(2), causing it to fail. Even if it
did not fail (i.e. reading of the already free'd piece of memory
yielded a directory path that we can chdir(2) to), it then gets
free(3)'d.

Fix this by making sure save_env() does do the saving when called.

While at it, add a minimal test for help.autocorrect facility.

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

mingw: disable mkfifo-based tests

MSYS2 (the POSIX emulation layer used by Git for Windows' Bash) actually
has a working mkfifo. The only problem is that it is only emulating
named pipes through the MSYS2 runtime; The Win32 API has no idea about
named pipes, hence the Git executable cannot access those pipes either.

The symptom is that Git fails with a '<name>: No such file or directory'
because MSYS2 emulates named pipes through special-crafted '.lnk' files.

The solution is to tell the test suite explicitly that we cannot use
named pipes when we want to test on Windows.

This lets t4056-diff-order.sh, t9010-svn-fe.sh and t9300-fast-import.sh
pass.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: accomodate t0060-path-utils for MSYS2

On Windows, there are no POSIX paths, only Windows ones (an absolute
Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under
most circumstances, forward slashes are also allowed and synonymous to
backslashes).

So when a POSIX shell (such as MSYS2's Bash, which is used by Git for
Windows to execute all those shell scripts that are part of Git) passes
a POSIX path to test-path-utils.exe (which is not POSIX-aware), the path
is translated into a Windows path. For example, /etc/profile becomes
C:/Program Files/Git/etc/profile.

This path translation poses a problem when passing the root directory as
parameter to test-path-utils.exe, as it is not well defined whether the
translated root directory should end in a slash or not. MSys1 stripped
the trailing slash, but MSYS2 does not.

Originally, the Git for Windows project patched MSYS2's runtime to
accomodate Git's regression test, but we really should do it the other
way round.

To work with both of MSys1's and MSYS2's behaviors, we simply test what
the current system does in the beginning of t0060-path-utils.sh and then
adjust the expected longest ancestor length accordingly.

It looks quite a bit tricky what we actually do in this patch: first, we
adjust the expected length for the trailing slash we did not originally
expect (subtracting one). So far, so good.

But now comes the part where things work in a surprising way: when the
expected length was 0, the prefix to match is the root directory. If the
root directory is converted into a path with a trailing slash, however,
we know that the logic in longest_ancestor_length() cannot match: to
avoid partial matches of the last directory component, it verifies that
the character after the matching prefix is a slash (but because the
slash was part of the matching prefix, the next character cannot be a
slash). So the return value is -1. Alas, this is exactly what the
expected length is after subtracting the value of $rootslash! So we skip
adding the $rootoff value in that case (and only in that case).

Directories other than the root directory are handled fine (as they are
specified without a trailing slash, something not possible for the root
directory, and MSYS2 converts them into Windows paths that also lack
trailing slashes), therefore we do not need any more special handling.

Thanks to Ray Donnelly for his patient help with this issue.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: fix t5601-clone.sh

Since baaf233 (connect: improve check for plink to reduce false
positives, 2015-04-26), t5601 writes out a `plink.exe` for testing that
is actually a shell script. So the assumption that the `.exe` extension
implies that the file is *not* a shell script is now wrong.

Since there was no love for the idea of allowing `.exe` files to be
shell scripts on Windows, let's go the other way round: *make*
`plink.exe` a real `.exe`.

This fixes t5601-clone.sh in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7063: add tests for core.untrackedCache

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-dump-untracked-cache: don't modify the untracked cache

To correctly perform its testing function,
test-dump-untracked-cache should not change the state of the
untracked cache in the index.

As a previous patch makes read_index_from() change the state of
the untracked cache and as test-dump-untracked-cache indirectly
calls this function, we need a mechanism to prevent
read_index_from() from changing the untracked cache state when
it's called from test-dump-untracked-cache.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: add core.untrackedCache

When we know that mtime on directory as given by the environment
is usable for the purpose of untracked cache, we may want the
untracked cache to be always used without any mtime test or
kernel name check being performed.

Also when we know that mtime is not usable for the purpose of
untracked cache, for example because the repo is shared over a
network file system, we may want the untracked-cache to be
automatically removed from the index.

Allow the user to express such preference by setting the
'core.untrackedCache' configuration variable, which can take
'keep', 'false', or 'true' and default to 'keep'.

When read_index_from() is called, it now adds or removes the
untracked cache in the index to respect the value of this
variable. So it does nothing if the value is `keep` or if the
variable is unset; it adds the untracked cache if the value is
`true`; and it removes the cache if the value is `false`.

`git update-index --[no-|force-]untracked-cache` still adds the
untracked cache to, or removes it, from the index, but this
shows a warning if it goes against the value of
core.untrackedCache, because the next time the index is read
the untracked cache will be added or removed if the
configuration is set to do so.

Also `--untracked-cache` used to check that the underlying
operating system and file system change `st_mtime` field of a
directory if files are added or deleted in that directory. But
because those tests take a long time, `--untracked-cache` no
longer performs them. Instead, there is now
`--test-untracked-cache` to perform the tests. This change
makes `--untracked-cache` the same as `--force-untracked-cache`.

This last change is backward incompatible and should be
mentioned in the release notes.

Helped-by: Duy Nguyen <pclouds@gmail.com>
Helped-by: Torsten Bögershausen <tboegi@web.de>
Helped-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
read-cache: Duy'sfixup

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-file: ensure that conflict sections match eol style

In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-file: let conflict markers match end-of-line style of the context

When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.

This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.

The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!

Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.

We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.

So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.

Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix auth parameter handling on SVN 1.9.0+

For users with "store-passwords = no" set in the "[auth]" section of
their ~/.subversion/config, SVN 1.9.0+ would fail with the
following message when attempting to call svn_auth_set_parameter:

Value is not a string (or undef) at Git/SVN/Ra.pm

Ironically, this breakage was caused by r1553823 in subversion:

"Make svn_auth_set_parameter() usable from Perl bindings."

Since 2007 (602015e0e6ec), git-svn has used a workaround to make
svn_auth_set_parameter usable internally. However this workaround
breaks under SVN 1.9+, which deals properly with the type mapping
and fails to recognize our workaround.

For pre-1.9.0 SVN, we continue to use the existing workaround for
the lack of proper type mapping in the bindings.

Tested under subversion 1.6.17 and 1.9.3.

I've also verified r1553823 was not backported to SVN 1.8.x:

BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x
svn log -v $BRANCH/subversion/bindings/swig/core.i

ref: https://bugs.debian.org/797705
Cc: 797705@bugs.debian.org
Reported-by: Thierry Vignaud <thierry.vignaud@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tested-by: Thierry Vignaud <thierry.vignaud@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Third batch for 2.8 cycle

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

Merge branch 'jk/symbolic-ref'

The low-level code that is used to create symbolic references has
been updated to share more code with the code that deals with
normal references.

* jk/symbolic-ref:
lock_ref_sha1_basic: handle REF_NODEREF with invalid refs
lock_ref_sha1_basic: always fill old_oid while holding lock
checkout,clone: check return value of create_symref
create_symref: write reflog while holding lock
create_symref: use existing ref-lock code
create_symref: modernize variable names

Merge branch 'ak/format-patch-odir-config'

"git format-patch" learned to notice format.outputDirectory
configuration variable. This allows "-o <dir>" option to be
omitted on the command line if you always use the same directory in
your workflow.

* ak/format-patch-odir-config:
format-patch: introduce format.outputDirectory configuration

Merge branch 'rp/p4-filetype-change'

* rp/p4-filetype-change:
git-p4.py: add support for filetype change

Merge branch 'js/close-packs-before-gc'

Many codepaths that run "gc --auto" before exiting kept packfiles
mapped and left the file descriptors to them open, which was not
friendly to systems that cannot remove files that are open. They
now close the packs before doing so.

* js/close-packs-before-gc:
receive-pack: release pack files before garbage-collecting
merge: release pack files before garbage-collecting
am: release pack files before garbage-collecting
fetch: release pack files before garbage-collecting

Merge branch 'jk/ok-to-fail-gc-auto-in-rebase'

"git rebase", unlike all other callers of "gc --auto", did not
ignore the exit code from "gc --auto".

* jk/ok-to-fail-gc-auto-in-rebase:
rebase: ignore failures from "gc --auto"

Merge branch 'js/pull-rebase-i'

"git pull --rebase" has been extended to allow invoking
"rebase -i".

* js/pull-rebase-i:
completion: add missing branch.*.rebase values
remote: handle the config setting branch.*.rebase=interactive
pull: allow interactive rebase with --rebase=interactive

mingw: let lstat() fail with errno == ENOTDIR when appropriate

POSIX semantics requires lstat() to fail with ENOTDIR when "[a]
component of the path prefix names an existing file that is neither a
directory nor a symbolic link to a directory".

See http://pubs.opengroup.org/onlinepubs/9699919799/functions/lstat.html

This behavior is expected by t1404-update-ref-df-conflicts now.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: try to delete target directory before renaming

When the rename() function tries to move a directory it fails if the
target directory exists. It should check if it can delete the (possibly
empty) target directory and then try again to move the directory.

This partially fixes t9100-git-svn-basic.sh.

Signed-off-by: 마누엘 <nalla@hamal.uberspace.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: prepare the TMPDIR environment variable for shell scripts

When shell scripts access a $TMPDIR variable containing backslashes,
they will be mistaken for escape characters. Let's not let that happen
by converting them to forward slashes.

This partially fixes t7800 with MSYS2.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: factor out Windows specific environment setup

We will add more environment-related code to that new function
in the next patch.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git.pm: stop assuming that absolute paths start with a slash

On Windows, absolute paths never start with a slash, unless a POSIX
emulation layer is used. The latter is the case for MSYS2's Perl that
Git for Windows leverages. However, in the tests we also go through
plain `git.exe`, which does *not* leverage the POSIX emulation layer,
and therefore the paths we pass to Perl may actually be DOS-style paths
such as C:/Program Files/Git.

So let's just use Perl's own way to test whether a given path is
absolute or not instead of home-brewing our own.

This patch partially fixes t7800 and t9700 when running in Git for
Windows' SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: do not trust MSYS2's MinGW gettext.sh

It does not quite work because it produces DOS line endings which the
shell does not like at all.

This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh,
t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh,
t7401-submodule-summary.sh, t7406-submodule-update.sh and
t7407-submodule-foreach.sh pass in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: let's use gettext with MSYS2

This solves two problems:

- we now have proper localisation even on Windows

- we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)"
message when running "git init" (which otherwise prevents the entire
test suite from running) because libintl.h overrides vsnprintf() with
libintl_vsnprintf() [*1*]

The latter issue is rather crucial, as *no* test passes in Git for
Windows without this fix.

Footnote *1*: gettext_git=http://git.savannah.gnu.org/cgit/gettext.git
$gettext_git/tree/gettext-runtime/intl/libgnuintl.in.h#n380

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: do not show ambiguous tag names as "tags/foo"

Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
git-tag has started showing tags with ambiguous names (i.e.,
when both "heads/foo" and "tags/foo" exists) as "tags/foo"
instead of just "foo". This is both:

- pointless; the output of "git tag" includes only
refs/tags, so we know that "foo" means the one in
"refs/tags".

and

- ambiguous; in the original output, we know that the line
"foo" means that "refs/tags/foo" exists. In the new
output, it is unclear whether we mean "refs/tags/foo" or
"refs/tags/tags/foo".

The reason this happens is that commit b7cc53e9 switched
git-tag to use ref-filter's "%(refname:short)" output
formatting, which was adapted from for-each-ref. This more
general code does not know that we care only about tags, and
uses shorten_unambiguous_ref to get the short-name. We need
to tell it that we care only about "refs/tags/", and it
should shorten with respect to that value.

In theory, the ref-filter code could figure this out by us
passing FILTER_REFS_TAGS. But there are two complications
there:

1. The handling of refname:short is deep in formatting
code that does not even have our ref_filter struct, let
alone the arguments to the filter_ref struct.

2. In git v2.7.0, we expose the formatting language to the
user. If we follow this path, it will mean that
"%(refname:short)" behaves differently for "tag" versus
"for-each-ref" (including "for-each-ref refs/tags/"),
which can lead to confusion.

Instead, let's add a new modifier to the formatting
language, "strip", to remove a specific set of prefix
components. This fixes "git tag", and lets users invoke the
same behavior from their own custom formats (for "tag" or
"for-each-ref") while leaving ":short" with its same
consistent meaning in all places.

We introduce a test in t7004 for "git tag", which fails
without this patch. We also add a similar test in t3203 for
"git branch", which does not actually fail. But since it is
likely that "branch" will eventually use the same formatting
code, the test helps defend against future regressions.

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

http: use credential API to handle proxy authentication

Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.

If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.

For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: allow selection of proxy authentication method

CURLAUTH_ANY does not work with proxies which answer unauthenticated requests
with a 307 redirect to an error page instead of a 407 listing supported
authentication methods. Therefore, allow the authentication method to be set
using the environment variable GIT_HTTP_PROXY_AUTHMETHOD or configuration
variables http.proxyAuthmethod and remote.<name>.proxyAuthmethod (in analogy
to http.proxy and remote.<name>.proxy).

The following values are supported:

* anyauth (default)
* basic
* digest
* negotiate
* ntlm

Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: explicity use container-based infrastructure

Set `sudo: false` to explicitly use the (faster) container-based
infrastructure for the Travis-CI Linux build.

More info:
https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: run previously failed tests first, then slowest to fastest

The Travis-CI machines are in a clean state in the beginning of every run
(transient by default). Use the Travis-CI cache feature to make the prove
state persistent across consecutive Travis-CI runs on the same branch.
This allows to run previously failed tests first and run remaining tests
in slowest to fastest order. As a result it is less likely that Travis-CI
needs to wait for a single test at the end which speeds up the test suite
execution by ~2 min.

Travis-CI can only cache entire directories. Prove stores the .prove file
always in the t/ directory but we don't want to cache the entire t/ directory.
Therefore we create a symlink from $HOME/travis-cache/.prove to t/.prove and
cache the $HOME/travis-cache directory.

Unfortunately the cache feature is only available (for free) on the
Travis-CI Linux environment.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: update completion arguments for stash

Add --all and --include-untracked to the git stash save completions.
Add --quiet to the git stash drop completions.
Update git stash branch so that the first argument expands out to the
possible branch names, and the other arguments expand to the stash
names.

Signed-off-by: Paul Wagland <paul@kungfoocoder.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: complete show-branch "--date-order"

Signed-off-by: Paul Wagland <paul@kungfoocoder.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: add missing git-rebase options

This adds the --no-* variants where those are documented in
git-rebase(1).

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: avoid linking to the C library's isalpha()

The implementation of mingw_skip_dos_drive_prefix() calls isalpha() via
has_dos_drive_prefix(). Since the definition occurs long before isalpha()
is defined in git-compat-util.h, my build environment reports:

CC alloc.o
In file included from git-compat-util.h:186,
from cache.h:4,
from alloc.c:12:
compat/mingw.h: In function 'mingw_skip_dos_drive_prefix':
compat/mingw.h:365: warning: implicit declaration of function 'isalpha'

Dscho does not see a similar warning in his build and suspects that
ctype.h is included somehow behind the scenes. This implies that his build
links to the C library's isalpha() and does not use git's isalpha().

To fix both the warning in my build and the inconsistency in Dscho's
build, move the function definition to mingw.c. Then it picks up git's
isalpha() because git-compat-util.h is included at the top of the file.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir: simplify untracked cache "ident" field

It is not a good idea to compare kernel versions and disable
the untracked cache if it changes, as people may upgrade and
still want the untracked cache to work. So let's just
compare work tree locations and kernel name to decide if we
should disable it.

Also storing many locations in the ident field and comparing
to any of them can be dangerous if GIT_WORK_TREE is used with
different values. So let's just store one location, the
location of the current work tree.

The downside is that untracked cache can only be used by one
type of OS for now. Exporting a git repo to different clients
via a network to e.g. Linux and Windows means that only one
can use the untracked cache.

If the location changed in the ident field and we still want
an untracked cache, let's delete the cache and recreate it.

Note that if an untracked cache has been created by a
previous Git version, then the kernel version is stored in
the ident field. As we now compare with just the kernel
name the comparison will fail and the untracked cache will
be disabled until it's recreated.

Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir: add remove_untracked_cache()

Factor out code into remove_untracked_cache(), which will be used
in a later commit.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir: add {new,add}_untracked_cache()

Factor out code into new_untracked_cache() and
add_untracked_cache(), which will be used
in later commits.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update-index: move 'uc' var declaration

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update-index: add untracked cache notifications

Attempting to flip the untracked-cache feature on for a random index
file with

cd /random/unrelated/place
git --git-dir=/somewhere/else/.git update-index --untracked-cache

would not work as you might expect. Because flipping the feature on
in the index also records the location of the corresponding working
tree (/random/unrelated/place in the above example), when the index
is subsequently used to keep track of files in the working tree in
/somewhere/else, the feature is disabled.

With this patch "git update-index --[test-]untracked-cache" tells the
user in which directory tests are performed. This makes it easy to
spot any problem.

Also in verbose mode, let's tell the user when the cache is enabled
or disabled.

Helped-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update-index: add --test-untracked-cache

It is nice to just be able to test if untracked cache is
supported without enabling it.

Helped-by: David Turner <dturner@twopensource.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update-index: use enum for untracked cache options

Helped-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6300: use test_atom for some un-modern tests

Because this script has to test so many formatters, we have
the nice "test_atom" helper, but we don't use it
consistently. Let's do so. This is shorter, gets rid of some
tests that have their "expected" setup outside of a
test_expect_success block, and lets us organize the changes
better (e.g., putting "refname:short" near "refname").

We also expand the "%(push)" tests a little to match the
"%(upstream)" ones.

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

resolve_gitlink_ref: ignore non-repository paths

When we want to look up a submodule ref, we use
get_ref_cache(path) to find or auto-create its ref cache.
But if we feed a path that isn't actually a git repository,
we blindly create the ref cache, and then may die deeper in
the code when we try to access it. This is a problem because
many callers speculatively feed us a path that looks vaguely
like a repository, and expect us to tell them when it is
not.

This patch teaches resolve_gitlink_ref to reject
non-repository paths without creating a ref_cache. This
avoids the die(), and also performs better if you have a
large number of these faux-submodule directories (because
the ref_cache lookup is linear, under the assumption that
there won't be a large number of submodules).

To accomplish this, we also break get_ref_cache into two
pieces: the lookup and auto-creation (the latter is lumped
into create_ref_cache). This lets us first cheaply ask our
cache "is it a submodule we know about?" If so, we can avoid
repeating our filesystem lookup. So lookups of real
submodules are not penalized; they examine the submodule's
.git directory only once.

The test in t3000 demonstrates a case where this improves
correctness (we used to just die). The new perf case in
p7300 shows off the speed improvement in an admittedly
pathological repository:

Test HEAD^ HEAD
----------------------------------------------------------------
7300.4: ls-files -o 66.97(66.15+0.87) 0.33(0.08+0.24) -99.5%

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

clean: make is_git_repository a public function

We have always had is_git_directory(), for looking at a
specific directory to see if it contains a git repo. In
0179ca7 (clean: improve performance when removing lots of
directories, 2015-06-15), we added is_git_repository() which
checks for a non-bare repository by looking at its ".git"
entry.

However, the fix in 0179ca7 needs to be applied other
places, too. Let's make this new helper globally available.
We need to give it a better name, though, to avoid confusion
with is_git_directory(). This patch does that, documents
both functions with a comment to reduce confusion, and
removes the clean-specific references in the comments.

Based-on-a-patch-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

worktree: stop supporting moving worktrees manually

The current update_linked_gitdir() has a bug that can create "gitdir"
file in non-multi-worktree setup. Worse, sometimes it can write relative
path to "gitdir" file, which will not work (e.g. "git worktree list"
will display the worktree's location incorrectly)

Instead of fixing this, we step back a bit. The original design was
probably not well thought out. For now, if the user manually moves a
worktree, they have to fix up "gitdir" file manually or the worktree
will get pruned.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ep/shell-command-substitution-style'

A shell script style update to change `command substitution` into
$(command substitution). Coverts contrib/ and much of the t/
directory contents.

* ep/shell-command-substitution-style: (92 commits)
t9901-git-web--browse.sh: use the $( ... ) construct for command substitution
t9501-gitweb-standalone-http-status.sh: use the $( ... ) construct for command substitution
t9350-fast-export.sh: use the $( ... ) construct for command substitution
t9300-fast-import.sh: use the $( ... ) construct for command substitution
t9150-svk-mergetickets.sh: use the $( ... ) construct for command substitution
t9145-git-svn-master-branch.sh: use the $( ... ) construct for command substitution
t9138-git-svn-authors-prog.sh: use the $( ... ) construct for command substitution
t9137-git-svn-dcommit-clobber-series.sh: use the $( ... ) construct for command substitution
t9132-git-svn-broken-symlink.sh: use the $( ... ) construct for command substitution
t9130-git-svn-authors-file.sh: use the $( ... ) construct for command substitution
t9129-git-svn-i18n-commitencoding.sh: use the $( ... ) construct for command substitution
t9119-git-svn-info.sh: use the $( ... ) construct for command substitution
t9118-git-svn-funky-branch-names.sh: use the $( ... ) construct for command substitution
t9114-git-svn-dcommit-merge.sh: use the $( ... ) construct for command substitution
t9110-git-svn-use-svm-props.sh: use the $( ... ) construct for command substitution
t9109-git-svn-multi-glob.sh: use the $( ... ) construct for command substitution
t9108-git-svn-glob.sh: use the $( ... ) construct for command substitution
t9107-git-svn-migrate.sh: use the $( ... ) construct for command substitution
t9105-git-svn-commit-diff.sh: use the $( ... ) construct for command substitution
t9104-git-svn-follow-parent.sh: use the $( ... ) construct for command substitution
...

Merge branch 'rm/subtree-unwrap-tags'

"git subtree" (in contrib/) records the tag object name in the
commit log message when a subtree is added using a tag, without
peeling it down to the underlying commit. The tag needs to be
peeled when "git subtree split" wants to work on the commit, but
the command forgot to do so.

* rm/subtree-unwrap-tags:
contrib/subtree: unwrap tag refs

unpack-trees: fix accidentally quadratic behavior

While unpacking trees (e.g. during git checkout), when we hit a cache
entry that's past and outside our path, we cut off iteration.

This provides about a 45% speedup on git checkout between master and
master^20000 on Twitter's monorepo. Speedup in general will depend on
repostitory structure, number of changes, and packfile packing
decisions.

Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: make -O and --output work in subdirectory

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: do not take a redundant prefix argument

Prefix is already set up in "revs". The same prefix should be used for
all options parsing. So kill the last argument. This patch does not
actually change anything because the only caller does use the same
prefix for init_revisions() and diff_no_index().

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add doc: do not say working directory when you mean working tree

The usage of working directory is inconsistent in the git add help.
Also http://git-scm.com/docs/git-clone speaks only about working tree.
Remaining entry found by "git grep -B1 '^directory' git-add.txt" really
relates to a directory.

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

completion: complete "diff --word-diff-regex="

Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>