Merge branch 'jc/diff-tree-stale-comment' into maint

Comment fix.

* jc/diff-tree-stale-comment:
  diff-tree: update stale in-code comments

Merge branch 'ps/stash-push-pathspec-fix' into maint

"git stash push <pathspec>" did not work from a subdirectory at all.
Bugfix for a topic in v2.13

* ps/stash-push-pathspec-fix:
  git-stash: fix pushing stash with pathspec from subdir

Merge branch 'ls/github' into maint

Help contributors that visit us at GitHub.

* ls/github:
  Configure Git contribution guidelines for github.com

Merge branch 'jk/pack-idx-corruption-safety' into maint

A flaky test has been corrected.

* jk/pack-idx-corruption-safety:
  t5313: make extended-table test more deterministic

Merge branch 'jk/diff-blob' into maint

The result from "git diff" that compares two blobs, e.g. "git diff
$commit1:$path $commit2:$path", used to be shown with the full
object name as given on the command line, but it is more natural to
use the $path in the output and use it to look up .gitattributes.

* jk/diff-blob:
  diff: use blob path for blob/file diffs
  diff: use pending "path" if it is available
  diff: use the word "path" instead of "name" for blobs
  diff: pass whole pending entry in blobinfo
  handle_revision_arg: record paths for pending objects
  handle_revision_arg: record modes for "a..b" endpoints
  t4063: add tests of direct blob diffs
  get_sha1_with_context: dynamically allocate oc->path
  get_sha1_with_context: always initialize oc->symlink_path
  sha1_name: consistently refer to object_context as "oc"
  handle_revision_arg: add handle_dotdot() helper
  handle_revision_arg: hoist ".." check out of range parsing
  handle_revision_arg: stop using "dotdot" as a generic pointer
  handle_revision_arg: simplify commit reference lookups
  handle_revision_arg: reset "dotdot" consistently

Merge branch 'jc/name-rev-lw-tag' into maint

"git describe --contains" penalized light-weight tags so much that
they were almost never considered.  Instead, give them about the
same chance to be considered as an annotated tag that is the same
age as the underlying commit would.

* jc/name-rev-lw-tag:
  name-rev: favor describing with tags and use committer date to tiebreak
  name-rev: refactor logic to see if a new candidate is a better name

Prepare for 2.13.2

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

Merge branch 'ad/pull-remote-doc' into maint

Docfix.

* ad/pull-remote-doc:
  docs: fix formatting and grammar

Merge branch 'jk/drop-free-refspecs' into maint

Code clean-up.

* jk/drop-free-refspecs:
  remote: drop free_refspecs() function

Merge branch 'jk/connect-symref-info-leak-fix' into maint

Leakfix.

* jk/connect-symref-info-leak-fix:
  connect.c: fix leak in parse_one_symref_info()

Merge branch 'rf/completion-config-commit' into maint

Completion update.

* rf/completion-config-commit:
  completion: add completions for git config commit

Merge branch 'ab/t3070-test-dedup' into maint

Test cleanup.

* ab/t3070-test-dedup:
  wildmatch test: remove redundant duplicate test

Merge branch 'jh/memihash-opt' into maint

perf-test update.

* jh/memihash-opt:
  p0004: don't error out if test repo is too small
  p0004: don't abort if multi-threaded is too slow
  p0004: use test_perf
  p0004: avoid using pipes
  p0004: simplify calls of test-lazy-init-name-hash

Merge branch 'tb/pull-ff-rebase-autostash' into maint

"git pull --rebase --autostash" didn't auto-stash when the local history
fast-forwards to the upstream.

* tb/pull-ff-rebase-autostash:
  pull: ff --rebase --autostash works in dirty repo

Merge branch 'jh/close-index-before-stat' into maint

The timestamp of the index file is now taken after the file is
closed, to help Windows, on which a stale timestamp is reported by
fstat() on a file that is opened for writing and data was written
but not yet closed.

* jh/close-index-before-stat:
  read-cache: close index.lock in do_write_index

Merge branch 'sl/clean-d-ignored-fix' into maint

"git clean -d" used to clean directories that has ignored files,
even though the command should not lose ignored ones without "-x".
"git status --ignored"  did not list ignored and untracked files
without "-uall".  These have been corrected.

* sl/clean-d-ignored-fix:
  clean: teach clean -d to preserve ignored paths
  dir: expose cmp_name() and check_contains()
  dir: hide untracked contents of untracked dirs
  dir: recurse into untracked dirs for ignored files
  t7061: status --ignored should search untracked dirs
  t7300: clean -d should skip dirs with ignored files

Merge branch 'dk/send-email-avoid-net-smtp-ssl-when-able' into maint

A hotfix to a topic in 'master'.

* dk/send-email-avoid-net-smtp-ssl-when-able:
  send-email: Net::SMTP::starttls was introduced in v2.34
  send-email: Net::SMTP::SSL is obsolete, use only when necessary

Merge branch 'jc/skip-test-in-the-middle' into maint

A recent update to t5545-push-options.sh started skipping all the
tests in the script when a web server testing is disabled or
unavailable, not just the ones that require a web server.  Non HTTP
tests have been salvaged to always run in this script.

* jc/skip-test-in-the-middle:
  t5545: enhance test coverage when no http server is installed
  test: allow skipping the remainder

Merge branch 'bw/forking-and-threading' into maint

The "run-command" API implementation has been made more robust
against dead-locking in a threaded environment.

* bw/forking-and-threading:
  usage.c: drop set_error_handle()
  run-command: restrict PATH search to executable files
  run-command: expose is_executable function
  run-command: block signals between fork and execve
  run-command: add note about forking and threading
  run-command: handle dup2 and close errors in child
  run-command: eliminate calls to error handling functions in child
  run-command: don't die in child when duping /dev/null
  run-command: prepare child environment before forking
  string-list: add string_list_remove function
  run-command: use the async-signal-safe execv instead of execvp
  run-command: prepare command before forking
  t0061: run_command executes scripts without a #! line
  t5550: use write_script to generate post-update hook

Merge branch 'jk/bug-to-abort' into maint

Introduce the BUG() macro to improve die("BUG: ...").

* jk/bug-to-abort:
  usage: add NORETURN to BUG() function definitions
  config: complain about --local outside of a git repo
  setup_git_env: convert die("BUG") to BUG()
  usage.c: add BUG() function

Merge branch 'sb/checkout-recurse-submodules' into maint

"git checkout --recurse-submodules" did not quite work with a
submodule that itself has submodules.

* sb/checkout-recurse-submodules:
  submodule: properly recurse for read-tree and checkout
  submodule: avoid auto-discovery in new working tree manipulator code
  submodule_move_head: reuse child_process structure for futher commands

Configure Git contribution guidelines for github.com

Many open source projects use github.com for their contribution process.
Although we mirror the Git core repository to github.com [1] we do not
use any other github.com service. This is unknown/unexpected to a
number of (potential) contributors and consequently they create Pull
Requests against our mirror with their contributions. These Pull
Requests become stale. This is frustrating to them as they think we
ignore them and it is also unsatisfactory for us as we miss potential
code improvements and/or new contributors.

GitHub contribution guidelines and a GitHub Pull Request template that
is visible to every Pull Request creator can be configured with special
files in a Git repository [2]. Let's make use of this!

[1] https://github.com/git/git
[2] https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/

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

git-stash: fix pushing stash with pathspec from subdir

The `git stash push` command recently gained the ability to get a
pathspec as its argument to only stash matching files. Calling this
command from a subdirectory does not work, though, as one of the first
things we do is changing to the top level directory without keeping
track of the prefix from which the command is being run.

Fix the shortcoming by storing the prefix previous to the call to
`cd_to_toplevel` and then subsequently using `git rev-parse --prefix` to
correctly resolve the pathspec. Add a test to catch future breakage of
this usecase.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ab/sha1dc-maint' into maint

* ab/sha1dc-maint:
  sha1dc: update from upstream
  sha1dc: ignore indent-with-non-tab whitespace violations

sha1dc: update from upstream

Update sha1dc from the latest version by the upstream
maintainer[1].

See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) for
the latest update. That update was done sans some whitespace changes
by upstream, which is why the diff here isn't the same as the upstream
cc46554..e139984.

It also brings in a change[2] upstream made which should hopefully
address the breakage in 2.13.1 on Cygwin, see [3]. Cygwin defines both
_BIG_ENDIAN and _LITTLE_ENDIAN.

Adam Dinwoodie reports on the mailing list that that upstream commit
fixes the issue on Cygwin[4].

1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/e1399840b501a68ac6c8d7ed9a5cb1455480200e
2. https://github.com/cr-marcstevens/sha1collisiondetection/commit/a24eef58c0684078405f8c7a89f9b78271432005
3. <20170606100355.GC25777@dinwoodie.org> (https://public-inbox.org/git/20170606100355.GC25777@dinwoodie.org/)
4. <20170606124323.GD25777@dinwoodie.org> (https://public-inbox.org/git/20170606124323.GD25777@dinwoodie.org/)

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1dc: ignore indent-with-non-tab whitespace violations

The upstream sha1dc code indents some lines with spaces.
While this doesn't match Git's coding guidelines, it's better
to leave this imported code untouched than to try to make it
match our style. However, we can use .gitattributes to tell
"diff --check" and "git am" not to bother us about it.

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

t5313: make extended-table test more deterministic

Commit a1283866b (t5313: test bounds-checks of
corrupted/malicious pack/idx files, 2016-02-25) added a test
that requires our corrupted pack index to have two objects.
The entry for the first one remains untouched, but we
corrupt the entry for second one. Since the index stores the
entries in sha1-sorted order, this means that the test must
make sure that the sha1 of the object we expect to be
corrupted ("$object") sorts after the other placeholder
object.

That commit used the HEAD commit as the placeholder, but the
script never calls test_tick. That means that the commit
object (and thus its sha1) depends on the timestamp when the
test script is run. This usually works in practice, because
the sha1 of $object starts with "fff". The commit object
will sort after that only 1 in 4096 times, but when it does
the test will fail.

One obvious solution is to add the test_tick call to get a
deterministic commit sha1. But since we're relying on the
sort order for the test to function, let's make that very
explicit by just generating a second blob with a known sha1.

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

Git 2.13.1

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

Merge branch 'ah/doc-rev-parse-short-default' into maint

Doc update.

* ah/doc-rev-parse-short-default:
  doc: rewrite description for rev-parse --short

Merge branch 'ah/doc-filter-branch-export-env' into maint

Docfix.

* ah/doc-filter-branch-export-env:
  doc: filter-branch does not require re-export of vars

Merge branch 'sd/t3200-typofix' into maint

Test fix.

* sd/t3200-typofix:
  branch test: fix invalid config key access

Merge branch 'sb/t5531-update-desc' into maint

The description strings for a few tests have been updated.

* sb/t5531-update-desc:
  t5531: fix test description

Merge branch 'ah/doc-pretty-format-fix' into maint

Documentation fix.

* ah/doc-pretty-format-fix:
  Documentation: fix formatting typo in pretty-formats.txt

Merge branch 'ah/doc-interpret-trailers-ifexists' into maint

Documentation fix.

* ah/doc-interpret-trailers-ifexists:
  Documentation: fix reference to ifExists for interpret-trailers

Merge branch 'ab/ref-filter-no-contains' into maint

Doc update to a recent topic.

* ab/ref-filter-no-contains:
  tag: duplicate mention of --contains should mention --no-contains

Merge branch 'sg/core-filemode-doc-typofix' into maint

* sg/core-filemode-doc-typofix:
  docs/config.txt: fix indefinite article in core.fileMode description

Merge branch 'tb/dedup-crlf-tests' into maint

* tb/dedup-crlf-tests:
  t0027: tests are not expensive; remove t0025

Merge branch 'jn/credential-doc-on-clear' into maint

Doc update.

* jn/credential-doc-on-clear:
  credential doc: make multiple-helper behavior more prominent

Merge branch 'jk/url-insteadof-config' into maint

The interaction of "url.*.insteadOf" and custom URL scheme's
whitelisting is now documented better.

* jk/url-insteadof-config:
  docs/config: mention protocol implications of url.insteadOf

Merge branch 'jk/unbreak-am-h' into maint

"git am -h" triggered a BUG().

* jk/unbreak-am-h:
  am: handle "-h" argument earlier

Merge branch 'ab/sha1dc-maint' into maint

The "collision detecting" SHA-1 implementation shipped with 2.13
was quite broken on some big-endian platforms and/or platforms that
do not like unaligned fetches.  Update to the upstream code which
has already fixed these issues.

* ab/sha1dc-maint:
  sha1dc: update from upstream

Merge branch 'js/bs-is-a-dir-sep-on-windows' into maint

"foo\bar\baz" in "git fetch foo\bar\baz", even though there is no
slashes in it, cannot be a nickname for a remote on Windows, as
that is likely to be a pathname on a local filesystem.

* js/bs-is-a-dir-sep-on-windows:
  Windows: do not treat a path with backslashes as a remote's nick name
  mingw.h: permit arguments with side effects for is_dir_sep

Merge branch 'jk/alternate-ref-optim' into maint

A test allowed both "git push" and "git receive-pack" on the other
end write their traces into the same file.  This is OK on platforms
that allows atomically appending to a file opened with O_APPEND,
but on other platforms led to a mangled output, causing
intermittent test failures.  This has been fixed by disabling
traces from "receive-pack" in the test.

* jk/alternate-ref-optim:
  t5400: avoid concurrent writes into a trace file

Merge branch 'bm/interpret-trailers-cut-line-is-eom' into maint

"git interpret-trailers", when used as GIT_EDITOR for "git commit
-v", looked for and appended to a trailer block at the very end,
i.e. at the end of the "diff" output.  The command has been
corrected to pay attention to the cut-mark line "commit -v" adds to
the buffer---the real trailer block should appear just before it.

* bm/interpret-trailers-cut-line-is-eom:
  interpret-trailers: honor the cut line

Merge branch 'kn/ref-filter-branch-list' into maint

"git for-each-ref --format=..." with %(HEAD) in the format used to
resolve the HEAD symref as many times as it had processed refs,
which was wasteful, and "git branch" shared the same problem.

* kn/ref-filter-branch-list:
  ref-filter: resolve HEAD when parsing %(HEAD) atom

Merge branch 'rs/checkout-am-fix-unborn' into maint

A few codepaths in "checkout" and "am" working on an unborn branch
tried to access an uninitialized piece of memory.

* rs/checkout-am-fix-unborn:
  am: check return value of resolve_refdup before using hash
  checkout: check return value of resolve_refdup before using hash

Merge branch 'jn/clone-add-empty-config-from-command-line' into maint

"git clone --config var=val" is a way to populate the
per-repository configuration file of the new repository, but it did
not work well when val is an empty string.  This has been fixed.

* jn/clone-add-empty-config-from-command-line:
  clone: handle empty config values in -c

Merge branch 'ab/c-translators-comment-style' into maint

Update the C style recommendation for notes for translators, as
recent versions of gettext tools can work with our style of
multi-line comments.

* ab/c-translators-comment-style:
  C style: use standard style for "TRANSLATORS" comments

Merge branch 'ls/travis-doc-asciidoctor' into maint

Travis CI gained a task to format the documentation with both
AsciiDoc and AsciiDoctor.

* ls/travis-doc-asciidoctor:
  travis-ci: check AsciiDoc/AsciiDoctor stderr output
  travis-ci: unset compiler for jobs that do not need one
  travis-ci: parallelize documentation build
  travis-ci: build documentation with AsciiDoc and Asciidoctor

Prepare for 2.13.1; more topics to follow

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

Merge branch 'tg/stash-push-fixup' into maint

The shell completion script (in contrib/) learned "git stash" has
a new "push" subcommand.

* tg/stash-push-fixup:
  completion: add git stash push

Merge branch 'km/log-showsignature-doc' into maint

Doc update.

* km/log-showsignature-doc:
  config.txt: add an entry for log.showSignature

Merge branch 'jt/use-trailer-api-in-commands' into maint

"git cherry-pick" and other uses of the sequencer machinery
mishandled a trailer block whose last line is an incomplete line.
This has been fixed so that an additional sign-off etc. are added
after completing the existing incomplete line.

* jt/use-trailer-api-in-commands:
  sequencer: add newline before adding footers

Merge branch 'jt/push-options-doc' into maint

The receive-pack program now makes sure that the push certificate
records the same set of push options used for pushing.

* jt/push-options-doc:
  receive-pack: verify push options in cert
  docs: correct receive.advertisePushOptions default

Merge branch 'js/plug-leaks' into maint

Fix memory leaks pointed out by Coverity (and people).

* js/plug-leaks: (26 commits)
  checkout: fix memory leak
  submodule_uses_worktrees(): plug memory leak
  show_worktree(): plug memory leak
  name-rev: avoid leaking memory in the `deref` case
  remote: plug memory leak in match_explicit()
  add_reflog_for_walk: avoid memory leak
  shallow: avoid memory leak
  line-log: avoid memory leak
  receive-pack: plug memory leak in update()
  fast-export: avoid leaking memory in handle_tag()
  mktree: plug memory leaks reported by Coverity
  pack-redundant: plug memory leak
  setup_discovered_git_dir(): plug memory leak
  setup_bare_git_dir(): help static analysis
  split_commit_in_progress(): simplify & fix memory leak
  checkout: fix memory leak
  cat-file: fix memory leak
  mailinfo & mailsplit: check for EOF while parsing
  status: close file descriptor after reading git-rebase-todo
  difftool: address a couple of resource/memory leaks
  ...

Merge branch 'js/eol-on-ourselves' into maint

Make sure our tests would pass when the sources are checked out
with "platform native" line ending convention by default on
Windows.  Some "text" files out tests use and the test scripts
themselves that are meant to be run with /bin/sh, ought to be
checked out with eol=LF even on Windows.

* js/eol-on-ourselves:
  t4051: mark supporting files as requiring LF-only line endings
  Fix the remaining tests that failed with core.autocrlf=true
  t3901: move supporting files into t/t3901/
  completion: mark bash script as LF-only
  git-new-workdir: mark script as LF-only
  Fix build with core.autocrlf=true

Merge branch 'jk/update-links-in-docs' into maint

A few http:// links that are redirected to https:// in the
documentation have been updated to https:// links.

* jk/update-links-in-docs:
  doc: use https links to Wikipedia to avoid http redirects

Merge branch 'jk/ignore-broken-tags-when-ignoring-missing-links' into maint

Tag objects, which are not reachable from any ref, that point at
missing objects were mishandled by "git gc" and friends (they
should silently be ignored instead)

* jk/ignore-broken-tags-when-ignoring-missing-links:
  revision.c: ignore broken tags with ignore_missing_links

Merge branch 'jk/doc-config-include' into maint

Clarify documentation for include.path and includeIf.<condition>.path
configuration variables.

* jk/doc-config-include:
  docs/config: consistify include.path examples
  docs/config: avoid the term "expand" for includes
  docs/config: give a relative includeIf example
  docs/config: clarify include/includeIf relationship

Merge branch 'jk/disable-pack-reuse-when-broken' into maint

"pack-objects" can stream a slice of an existing packfile out when
the pack bitmap can tell that the reachable objects are all needed
in the output, without inspecting individual objects.  This
strategy however would not work well when "--local" and other
options are in use, and need to be disabled.

* jk/disable-pack-reuse-when-broken:
  t5310: fix "; do" style
  pack-objects: disable pack reuse for object-selection options

Merge branch 'jk/am-leakfix' into maint

The codepath in "git am" that is used when running "git rebase"
leaked memory held for the log message of the commits being rebased.

* jk/am-leakfix:
  am: shorten ident_split variable name in get_commit_info()
  am: simplify allocations in get_commit_info()
  am: fix commit buffer leak in get_commit_info()

Merge branch 'jc/read-tree-empty-with-m' into maint

"git read-tree -m" (no tree-ish) gave a nonsense suggestion "use
--empty if you want to clear the index".  With "-m", such a request
will still fail anyway, as you'd need to name at least one tree-ish
to be merged.

* jc/read-tree-empty-with-m:
  read-tree: "read-tree -m --empty" does not make sense

Merge branch 'jc/apply-fix-mismerge' into maint

Mismerge fix.

* jc/apply-fix-mismerge:
  apply.c: fix whitespace-only mismerge

Merge branch 'ja/do-not-ask-needless-questions' into maint

Git sometimes gives an advice in a rhetorical question that does
not require an answer, which can confuse new users and non native
speakers.  Attempt to rephrase them.

* ja/do-not-ask-needless-questions:
  git-filter-branch: be more direct in an error message
  read-tree -m: make error message for merging 0 trees less smart aleck
  usability: don't ask questions if no reply is required

Merge branch 'bw/submodule-with-bs-path' into maint

A hotfix to a topic that is already in v2.13.

* bw/submodule-with-bs-path:
  t7400: add !CYGWIN prerequisite to 'add with \\ in path'

Merge branch 'ah/log-decorate-default-to-auto' into maint

Setting "log.decorate=false" in the configuration file did not take
effect in v2.13, which has been corrected.

* ah/log-decorate-default-to-auto:
  builtin/log: honor log.decorate

Merge branch 'ab/fix-poison-tests' into maint

Update tests to pass under GETTEXT_POISON (a mechanism to ensure
that output strings that should not be translated are not
translated by mistake), and tell TravisCI to run them.

* ab/fix-poison-tests:
  travis-ci: add job to run tests with GETTEXT_POISON
  travis-ci: setup "prove cache" in "script" step
  tests: fix tests broken under GETTEXT_POISON=YesPlease

Merge branch 'ab/doc-replace-gmane-links' into maint

The Web interface to gmane news archive is long gone, even though
the articles are still accessible via NTTP.  Replace the links with
ones to public-inbox.org.  Because their message identification is
based on the actual message-id, it is likely that it will be easier
to migrate away from it if/when necessary.

* ab/doc-replace-gmane-links:
  doc: replace more gmane links
  doc: replace a couple of broken gmane links

Merge branch 'ab/aix-needs-compat-regex' into maint

Build fix.

* ab/aix-needs-compat-regex:
  config.mak.uname: set NO_REGEX=NeedsStartEnd on AIX

Merge branch 'pw/rebase-i-regression-fix' into maint

Just the first one of three? new tests that follows up a regression
fix.

* pw/rebase-i-regression-fix:
  rebase -i: add missing newline to end of message
  rebase -i: silence stash apply
  rebase -i: fix reflog message

docs: fix formatting and grammar

When compiling the documentation, asciidoc thinks a backtick surrounded
by whitespace shouldn't be interpreted as marking the start or end of a
literal.  In most cases, that's useful behaviour, but in the git-pull
documentation it means asciidoc is failing to correctly detect which
text should be monospaced and which shouldn't.

To avoid this, remove the extraneous spaces from the text to be
monospaced.  It would also be possible to fix the formatting by
switching to asciidoc's ++ monospace format markers and still have the
space characters included in the monospace text, but the spaces aren't
necessary and not having them keeps the markup simpler.

Also include a minor grammar fix suggested by Jeff while we're changing
these lines.

Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-tree: update stale in-code comments

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

pull: ff --rebase --autostash works in dirty repo

When `git pull --rebase --autostash` in a dirty repository resulted in a
fast-forward, nothing was being autostashed and the pull failed. This
was due to a shortcut to avoid running rebase when we can fast-forward,
but autostash is ignored on that codepath.

Now we will only take the shortcut if autostash is not in effect.
Based on a few tests against the git.git repo, the shortcut does not
seem to give us significant performance benefits, on Linux at least.
Regardless, it is more important to be correct than to be fast.

Signed-off-by: Tyler Brazier <tyler@tylerbrazier.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: Net::SMTP::starttls was introduced in v2.34

We cannot rely on the starttls method being present in Net::SMTP until
c274b798e6881a941d941808c6d89966975cb8c8 (Merge branch 'ipv6_ssl' of
https://github.com/noxxi/perl-libnet into noxxi-ipv6_ssl, 2014-06-02),
which set the module version to 2.34.

This version was first shipped as part of perl in v5.21.5~169 (Update
libnet to CPAN version 3.01, 2014-10-10).

Noticed on an Ubuntu system with perl 5.18.2-2ubuntu1.1, which
provides Net::SMTP version 2.31. The error message is

  Can't locate object method "starttls" via package "Net::SMTP" at /usr/lib/git-core/git-send-email line 1410.

Reported-by: Brandon Williams <bmwill@google.com>
Reported-and-tested-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: rewrite description for rev-parse --short

`git rev-parse --short` is not a generic modifier but just a variant
of `--verify` and considers the given length only as a suggestion to
ensure uniqueness.

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs/config: mention protocol implications of url.insteadOf

If a URL rewrite switches the protocol to something
nonstandard (like "persistent-https" for "https"), the user
may be bitten by the fact that the default protocol
restrictions are different between the two. Let's drop a
note in insteadOf that points the user in the right
direction.

It would be nice if we could make this work out of the box,
but we can't without knowing the security implications of
the user's rewrite. Only the documentation for a particular
remote helper can advise one way or the other. Since we do
include the persistent-https helper in contrib/ (and since
it was the helper in the real-world case that inspired that
patch), let's also drop a note there.

Suggested-by: Elliott Cable <me@ell.io>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: drop free_refspecs() function

We already have free_refspec(), a public function which does
the same thing as the static free_refspecs(). Let's just
keep one.  There are two minor differences between the
functions:

  1. free_refspecs() is a noop when the refspec argument is
     NULL. This probably doesn't matter in practice.  The
     nr_refspec parameter would presumably be 0 in that
     case, skipping the loop. And free(NULL) is explicitly
     OK. But it doesn't hurt for us to port this extra
     safety to free_refspec(), as one of the callers passes
     a funny "i+1" count.

  2. The order of arguments is reversed between the two
     functions. This patch uses the already-public order of
     free_refspec(), as it matches the argument order on the
     parsing side.

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

C style: use standard style for "TRANSLATORS" comments

Change all the "TRANSLATORS: [...]" comments in the C code to use the
regular Git coding style, and amend the style guide so that the
example there uses that style.

This custom style was necessary back in 2010 when the gettext support
was initially added, and was subsequently documented in commit
cbcfd4e3ea ("i18n: mention "TRANSLATORS:" marker in
Documentation/CodingGuidelines", 2014-04-18).

GNU xgettext hasn't had the parsing limitation that necessitated this
exception for almost 3 years. Since its 0.19 release on 2014-06-02
it's been able to recognize TRANSLATOR comments in the standard Git
comment syntax[1].

Usually we'd like to keep compatibility with software that's that
young, but in this case literally the only person who needs to be
using a gettext newer than 3 years old is Jiang Xin (the only person
who runs & commits "make pot" results), so I think in this case we can
make an exception.

This xgettext parsing feature was added after a thread on the Git
mailing list[2] which continued on the bug-gettext[3] list, but we
never subsequently changed our style & styleguide, do so.

There are already longstanding changes in git that use the standard
comment style & have their TRANSLATORS comments extracted properly
without getting the literal "*"'s mixed up in the text, as would
happen before xgettext 0.19.

Commit 7ff2683253 ("builtin-am: implement -i/--interactive",
2015-08-04) added one such comment, which in commit df0617bfa7 ("l10n:
git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked
up in the po/git.pot file with the right format, showing that Jiang
already runs a modern xgettext.

The xgettext parser does not handle the sort of non-standard comment
style that I'm amending here in sequencer.c, but that isn't standard
Git comment syntax anyway. With this change to sequencer.c & "make
pot" the comment in the pot file is now correct:

     #. TRANSLATORS: %s will be "revert", "cherry-pick" or
    -#. * "rebase -i".
    +#. "rebase -i".

1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd
2. <2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com>
   (https://public-inbox.org/git/2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com/)
3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.html

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am: handle "-h" argument earlier

If the user provides "-h" on the command line, then our
parse_options() invocation will show a usage message and
quit. But if "-h" is the only argument, the git wrapper
behaves specially: it ignores our RUN_SETUP flag and calls
cmd_am() without having done repository setup at all.  This
is due to 99caeed05 (Let 'git <command> -h' show usage
without a git dir, 2009-11-09).

Before cmd_am() calls parse_options(), though, it runs a few
other setup functions. One of these is am_state_init(),
which uses git_pathdup() to set up the default rebase-apply
path. But calling git_pathdup() when we haven't done
repository setup will fall back to using ".git". That's
mostly harmless (since we won't use the value anyway), but
is forbidden since b1ef400eec ("setup_git_env: avoid blind
fall-back to ".git"", 2016-10-20), and we now BUG().

We can't easily move that setup to after the parse_options()
call; the point is to set up defaults that are overwritten
by the option parsing. Instead, we'll detect the "-h" case
early and show the usage then. This matches the behavior of
other builtins which have a similar setup-ordering issue
(e.g., git-branch).

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

completion: add completions for git config commit

Add missing completions for git config:

* commit.cleanup
* commit.gpgSign
* commit.verbose

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch test: fix invalid config key access

Fixes the test by changing "branch.s/s/dummy" to "branch.s/s.dummy" which is
the right way of accessing config key "branch.s/s.dummy". Purpose of
this test is to confirm that this key doesn't exist after the branch
"s/s" has been renamed to "s".

Earlier it was trying to access invalid config key and hence was getting
an error. However, this wasn't caught because we were expecting the
command to fail for other reason as mentioned above.

Signed-off-by: Sahil Dua <sahildua2305@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wildmatch test: remove redundant duplicate test

Remove a test line that's exactly the same as the preceding
line.

This was brought in in commit feabcc173b ("Integrate wildmatch to
git", 2012-10-15), these tests are originally copied from rsync.git,
but the duplicate line was never present there, so must have just
snuck in during integration with git by accident.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: filter-branch does not require re-export of vars

The function `set_ident` in `filter-branch` exported the variables
GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007.
Therefore the filter scripts don't need to re-eport them again.

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

connect.c: fix leak in parse_one_symref_info()

If we successfully parse a symref value like
"HEAD:refs/heads/master", we add the result to a string
list. But because the string list is marked
STRING_LIST_INIT_DUP, the string list code will make a copy
of the string and add the copy.

This patch fixes it by adding the entry with
string_list_append_nodup(), which lets the string list take
ownership of our newly allocated string. There are two
alternatives that seem like they would work, but aren't the
right solution.

The first is to initialize the list with the "NODUP"
initializer. That would avoid the copy, but then the string
list would not realize that it owns the strings. When we
eventually call string_list_clear(), it would not free the
strings, causing a leak.

The second option would be to use the normal
string_list_append(), but free the local copy in our
function. We can't do this because the local copy actually
contains _two_ strings; the symref name and its target. We
point to the target pointer via the "util" field, and its
memory must last as long as the string list does.

You may also wonder whether it's safe to ever free the local
copy, since the target points into it. The answer is yes,
because we duplicate it in annotaate_refs_with_symref_info
before clearing the string list.

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

docs/config.txt: fix indefinite article in core.fileMode description

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Windows: do not treat a path with backslashes as a remote's nick name

On Windows, the remote repository name in, e.g., `git fetch foo\bar`
is clearly not a nickname for a configured remote repository. However,
the function valid_remote_nick() does not account for backslashes.
Use is_dir_sep() to check for both slashes and backslashes on Windows.

This was discovered while playing with Duy's patches that warn after
fopen() failures. The functions that read the branches and remotes
files are protected by a valid_remote_nick() check. Without this
change, a Windows style absolute path is incorrectly regarded as
nickname and is concatenated to a prefix and used with fopen(). This
triggers warnings because a colon in a path name is not allowed:

C:\Temp\gittest>git fetch C:\Temp\gittest
warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument
warning: unable to access '.git/branches/C:\Temp\gittest': Invalid argument
From C:\Temp\gittest
 * branch            HEAD       -> FETCH_HEAD

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

diff: use blob path for blob/file diffs

When we diff a blob against a working tree file like:

  git diff HEAD:Makefile Makefile

we always use the working tree filename for both sides of
the diff. In most cases that's fine, as the two would be the
same anyway, as above. And until recently, we used the
"name" for the blob, not the path, which would have the
messy "HEAD:" on the beginning.

But when they don't match, like:

  git diff HEAD:old_path new_path

it makes sense to show both names.

This patch uses the blob's path field if it's available, and
otherwise falls back to using the filename (in preference to
the blob's name, which is likely to be garbage like a raw
sha1).

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

diff: use pending "path" if it is available

There's a subtle distinction between "name" and "path" for a
blob that we resolve: the name is what the user told us on
the command line, and the path is what we traversed when
finding the blob within a tree (if we did so).

When we diff blobs directly, we use "name", but "path" is
more likely to be useful to the user (it will find the
correct .gitattributes, and give them a saner diff header).

We still have to fall back to using the name for some cases
(i.e., any blob reference that isn't of the form tree:path).
That's the best we can do in such a case.

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

diff: use the word "path" instead of "name" for blobs

The stuff_change() function makes diff_filespecs out of
blobs. The term we generally use for filespecs is "path",
not "name", so let's be consistent here.  That will make
things less confusing when the next patch starts caring
about the path/name distinction inside the pending object
array.

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

diff: pass whole pending entry in blobinfo

When diffing blobs directly, git-diff picks the blobs out of
the rev_info's pending array and copies the relevant bits to
a custom "struct blobinfo". But the pending array entry
already has all of this information (and more, which we'll
use in future patches). Let's just pass the original entry
instead.

In practice, these two blobs are probably adjacent in the
revs->pending array, and we could just pass the whole array.
But the current code is careful to pick each blob out
separately and put it into another array, so we'll continue
to do so and make our own array-of-pointers.

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

handle_revision_arg: record paths for pending objects

If the revision parser sees an argument like tree:path, we
parse it down to the correct blob (or tree), but throw away
the "path" portion. Let's ask get_sha1_with_context() to
record it, and pass it along in the pending array.

This will let programs like git-diff which rely on the
revision-parser show more accurate paths.

Note that the implementation is a little tricky; we have to
make sure we free oc.path in all code paths. For handle_dotdot(),
we can piggy-back on the existing cleanup-wrapper pattern.
The real work happens in handle_dotdot_1(), but the
handle_dotdot() wrapper makes sure that the path is freed no
matter how we exit the function (and for that reason we make
sure that the object_context struct is zero'd, so if we fail
to even get to the get_sha1_with_context() call, we just end
up calling free(NULL)).

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

handle_revision_arg: record modes for "a..b" endpoints

The "a..b" revision syntax was designed to handle commits,
so it doesn't bother to record any mode we find while
traversing a "tree:path" endpoint. These days "git diff" can
diff blobs using either "a:path..b:path" (with dots) or
"a:path b:path" (without), but the two behave
inconsistently, as the with-dots version fails to notice the
mode.

Let's teach the dot-dot range parser to record modes; it
doesn't cost us anything, and it makes this case work.

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

t4063: add tests of direct blob diffs

The git-diff command can directly compare two blobs (or a
blob and a file), but we don't test this at all. Let's add
some basic tests that reveal a few problems.

There are basically four interesting inputs:

  1. sha1 against sha1 (where diff has no information beyond
     the contents)

  2. tree:path against tree:path (where it can get
     information via get_sha1_with_context)

  3. Same as (2), but using the ".." range syntax

  4. tree:path against a filename

And beyond generating a sane diff, we care about a few
little bits: which paths they show in the diff header, and
whether they correctly pick up a mode change.

They should all be able to show a mode except for (1),
though note that case (3) is currently broken.

For the headers, we would ideally show the path within the
tree if we have it, making:

  git diff a:path b:path

look the same as:

  git diff a b -- path

We can't always do that (e.g., in the direct sha1/sha1 diff,
we have no path to show), in which case we should fall back
to the name that resolved to the blob (which is nonsense
from the repository's perspective, but is the best we can
do).

Aside from the fallback case in (1), none of the cases get
this right. Cases (2) and (3) always show the full
tree:path, even though we should be able to know just the
"path" portion.

Case (4) picks up the filename path, but assigns it to
_both_ sides of the diff. So this works for:

  git diff tree:path path

but not for:

  git diff tree:other_path path

The appropriate tests are marked to expect failure.

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

get_sha1_with_context: dynamically allocate oc->path

When a sha1 lookup returns the tree path via "struct
object_context", it just copies it into a fixed-size buffer.
This means the result can be truncated, and it means our
"struct object_context" consumes a lot of stack space.

Instead, let's allocate a string on the heap. Because most
callers don't care about this information, we'll avoid doing
it by default (so they don't all have to start calling
free() on the result). There are basically two options for
the caller to signal to us that it's interested:

  1. By setting a pointer to storage in the object_context.

  2. By passing a flag in another parameter.

Doing (1) would match the way that sha1_object_info_extended()
works. But it would mean that every caller would have to
initialize the object_context, which they don't currently
have to do.

This patch does (2), and adds a new bit to the function's
flags field. All of the callers that look at the "path"
field are updated to pass the new flag.

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

get_sha1_with_context: always initialize oc->symlink_path

The get_sha1_with_context() function zeroes out the
oc->symlink_path strbuf, but doesn't use strbuf_init() to
set up the usual invariants (like pointing to the slopbuf).
We don't actually write to the oc->symlink_path strbuf
unless we call get_tree_entry_follow_symlinks(), and that
function does initialize it. However, readers may still look
at the zero'd strbuf.

In practice this isn't a triggerable bug. The only caller
that looks at it only does so when the mode we found is 0.
This doesn't happen for non-tree-entries (where we return
S_IFINVALID). A broken tree entry could have a mode of 0,
but canon_mode() quietly rewrites that into S_IFGITLINK.
So the "0" mode should only come up when we did indeed find
a symlink.

This is mostly just an accident of how the code happens to
work, though. Let's future-proof ourselves to make sure the
strbuf is properly initialized for all calls (it's only a
few struct member assignments, not a heap allocation).

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

sha1_name: consistently refer to object_context as "oc"

An early version of the patch to add object_context used the
name object_resolve_context. This was later shortened to
just object_context, but the "orc" variable name stuck in a
few places.  Let's use "oc", which is used elsewhere in the
code.

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

handle_revision_arg: add handle_dotdot() helper

The handle_revision_arg function is rather long, and a big
chunk of it is handling the range operators. Let's pull that
out to a separate helper. While we're doing so, we can clean
up a few of the rough edges that made the flow hard to
follow:

  - instead of manually restoring *dotdot (that we overwrote
    with a NUL), do the real work in a sub-helper, which
    makes it clear that the munge/restore lines are a
    matched pair

  - eliminate a goto which wasn't actually used for control
    flow, but only to avoid duplicating a few lines
    (instead, those lines are pushed into another helper
    function)

  - use early returns instead of deep nesting

  - consistently name all variables for the left-hand side
    of the range as "a" (rather than "this" or "from") and
    the right-hand side as "b" (rather than "next", or using
    the unadorned "sha1" or "flags" from the main function).

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

handle_revision_arg: hoist ".." check out of range parsing

Since 003c84f6d (specifying ranges: we did not mean to make
".." an empty set, 2011-05-02), we treat the argument ".."
specially. We detect it by noticing that both sides of the
range are empty, and that this is a non-symmetric two-dot
range.

While correct, this makes the code overly complicated. We
can just detect ".." up front before we try to do further
parsing. This avoids having to de-munge the NUL from dotdot,
and lets us eliminate an extra const array (which we needed
only to do direct pointer comparisons).

It also removes the one code path from the range-parsing
conditional that requires us to return -1. That will make it
simpler to pull the dotdot parsing out into its own
function.

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

handle_revision_arg: stop using "dotdot" as a generic pointer

The handle_revision_arg() function has a "dotdot" variable
that it uses to find a ".." or "..." in the argument. If we
don't find one, we look for other marks, like "^!". But we
just keep re-using the "dotdot" variable, which is
confusing.

Let's introduce a separate "mark" variable that can be used
for these other marks. They still reuse the same variable,
but at least the name is no longer actively misleading.

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

handle_revision_arg: simplify commit reference lookups

The "dotdot" range parser avoids calling
lookup_commit_reference() if we are directly fed two
commits. But its casts are unnecessarily complex; that
function will just return a commit we pass into it.

Just calling the function all the time is much simpler, and
doesn't do any significant extra work (the object is already
parsed, and deref_tag() on a non-tag is a noop; we do incur
one extra lookup_object() call, but that's fairly trivial).

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