Multi-ref transaction support we merged a few releases ago
unnecessarily kept many file descriptors open, risking to fail with
resource exhaustion.  This is for 2.4.x track.

* mh/write-refs-sooner-2.4:
  ref_transaction_commit(): fix atomicity and avoid fd exhaustion
  ref_transaction_commit(): remove the local flags variable
  ref_transaction_commit(): inline call to write_ref_sha1()
  rename_ref(): inline calls to write_ref_sha1() from this function
  commit_ref_update(): new function, extracted from write_ref_sha1()
  write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
  t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
  update-ref: test handling large transactions properly
  ref_transaction_commit(): fix atomicity and avoid fd exhaustion
  ref_transaction_commit(): remove the local flags variable
  ref_transaction_commit(): inline call to write_ref_sha1()
  rename_ref(): inline calls to write_ref_sha1() from this function
  commit_ref_update(): new function, extracted from write_ref_sha1()
  write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
  t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
  update-ref: test handling large transactions properly

The "log --decorate" enhancement in Git 2.4 that shows the commit
at the tip of the current branch e.g. "HEAD -> master", did not
work with --decorate=full.

* mg/log-decorate-HEAD:
  log: do not shorten decoration names too early
  log: decorate HEAD with branch name under --decorate=full, too

Various documentation mark-up fixes to make the output more
consistent in general and also make AsciiDoctor (an alternative
formatter) happier.

* jk/asciidoc-markup-fix:
  doc: convert AsciiDoc {?foo} to ifdef::foo[]
  doc: put example URLs and emails inside literal backticks
  doc: drop backslash quoting of some curly braces
  doc: convert \--option to --option
  doc/add: reformat `--edit` option
  doc: fix length of underlined section-title
  doc: fix hanging "+"-continuation
  doc: fix unquoted use of "{type}"
  doc: fix misrendering due to `single quote'

A literal block in the tutorial had lines with unequal lengths to
delimit it from the rest of the document, which choke GitHub's
AsciiDoc renderer.

* jk/stripspace-asciidoctor-fix:
  doc: fix unmatched code fences in git-stripspace

A literal block in the tutorial had lines with unequal lengths to
delimit it from the rest of the document, which choke GitHub's
AsciiDoc renderer.

* ja/tutorial-asciidoctor-fix:
  doc: fix unmatched code fences

A preparatory clean-up step.

* sg/help-subcommands:
  command-list.txt: fix whitespace inconsistency

"git bundle verify" did not diagnose extra parameters on the
command line.

* ps/bundle-verify-arg:
  bundle: verify arguments more strictly

Introduce http.<url>.SSLCipherList configuration variable to tweak
the list of cipher suite to be used with libcURL when talking with
https:// sites.

* ls/http-ssl-cipher-list:
  http: add support for specifying an SSL cipher list

"git subtree" script (in contrib/) used "echo -n" to produce
progress messages in a non-portable way.

* dl/subtree-avoid-tricky-echo:
  contrib/subtree: portability fix for string printing

Test clean-up.

* jk/skip-http-tests-under-no-curl:
  tests: skip dav http-push tests under NO_EXPAT=NoThanks
  t/lib-httpd.sh: skip tests if NO_CURL is defined

"git subtree" script (in contrib/) does not have --squash option
when pushing, but the documentation and help text pretended as if
it did.

* dl/subtree-push-no-squash:
  contrib/subtree: there's no push --squash

The Git subcommand completion (in contrib/) listed credential
helpers among candidates, which is not something the end user would
invoke interatively.

* sg/completion-omit-credential-helpers:
  completion: remove credential helpers from porcelain commands

Error messages from "git branch" called remote-tracking branches as
"remote branches".

* dl/branch-error-message:
  branch: do not call a "remote-tracking branch" a "remote branch"

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

The refs API uses ref_lock struct which had its own "int fd", even
though the same file descriptor was in the lock struct it contains.
Clean-up the code to lose this redundant field.

* sb/ref-lock-lose-lock-fd:
  refs.c: remove lock_fd from struct ref_lock

Add the "--allow-unknown-type" option to "cat-file" to allow
inspecting loose objects of an experimental or a broken type.

* kn/cat-file-literally:
  t1006: add tests for git cat-file --allow-unknown-type
  cat-file: teach cat-file a '--allow-unknown-type' option
  cat-file: make the options mutually exclusive
  sha1_file: support reading from a loose object of unknown type

A heuristic to help the "git <cmd> <revs> <pathspec>" command line
convention to catch mistyped paths is to make sure all the non-rev
parameters in the later part of the command line are names of the
files in the working tree, but that means "git grep $str -- \*.c"
must always be disambiguated with "--", because nobody sane will
create a file whose name literally is asterisk-dot-see.  Loosen the
heuristic to declare that with a wildcard string the user likely
meant to give us a pathspec.

* nd/dwim-wildcards-as-pathspecs:
  pathspec: avoid the need of "--" when wildcard is used

"git merge FETCH_HEAD" learned that the previous "git fetch" could
be to create an Octopus merge, i.e. recording multiple branches
that are not marked as "not-for-merge"; this allows us to lose an
old style invocation "git merge <msg> HEAD $commits..." in the
implementation of "git pull" script; the old style syntax can now
be deprecated.

* jc/merge:
  merge: deprecate 'git merge <message> HEAD <commit>' syntax
  merge: handle FETCH_HEAD internally
  merge: decide if we auto-generate the message early in collect_parents()
  merge: make collect_parents() auto-generate the merge message
  merge: extract prepare_merge_message() logic out
  merge: narrow scope of merge_names
  merge: split reduce_parents() out of collect_parents()
  merge: clarify collect_parents() logic
  merge: small leakfix and code simplification
  merge: do not check argc to determine number of remote heads
  merge: clarify "pulling into void" special case
  t5520: test pulling an octopus into an unborn branch
  t5520: style fixes
  merge: simplify code flow
  merge: test the top-level merge driver

"git rebase -i" moved the "current" command from "todo" to "done" a
bit too prematurely, losing a step when a "pick" did not even start.

* ph/rebase-i-redo:
  rebase -i: redo tasks that die during cherry-pick

Help us to find broken test script that splits the body part of the
test by mistaken use of wrong kind of quotes.

* jc/test-prereq-validate:
  test: validate prerequistes syntax

The connection initiation code for "ssh" transport tried to absorb
differences between the stock "ssh" and Putty-supplied "plink" and
its derivatives, but the logic to tell that we are using "plink"
variants were too loose and falsely triggered when "plink" appeared
anywhere in the path (e.g. "/home/me/bin/uplink/ssh").

* bc/connect-plink:
  connect: improve check for plink to reduce false positives
  t5601: fix quotation error leading to skipped tests
  connect: simplify SSH connection code path

Developer support to automatically detect broken &&-chain in the
test scripts is now turned on by default.

* jk/test-chain-lint:
  test-lib: turn on GIT_TEST_CHAIN_LINT by default
  t7502-commit.sh: fix a broken and-chain

* fg/document-commit-message-stripping:
  Documentation: clarify how "git commit" cleans up the edited log message

"git stash pop/apply" forgot to make sure that not just the working
tree is clean but also the index is clean. The latter is important
as a stash application can conflict and the index will be used for
conflict resolution.

* jk/stash-require-clean-index:
  stash: require a clean index to apply
  t3903: avoid applying onto dirty index
  t3903: stop hard-coding commit sha1s

We have prepended $GIT_EXEC_PATH and the path "git" is installed in
(typically "/usr/bin") to $PATH when invoking subprograms and hooks
for almost eternity, but the original use case the latter tried to
support was semi-bogus (i.e. install git to /opt/foo/git and run it
without having /opt/foo on $PATH), and more importantly it has
become less and less relevant as Git grew more mainstream (i.e. the
users would _want_ to have it on their $PATH).  Stop prepending the
path in which "git" is installed to users' $PATH, as that would
interfere the command search order people depend on (e.g. they may
not like versions of programs that are unrelated to Git in /usr/bin
and want to override them by having different ones in /usr/local/bin
and have the latter directory earlier in their $PATH).

* jk/git-no-more-argv0-path-munging:
  stop putting argv[0] dirname at front of PATH

core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed
to be overridden by repository-specific .git/info/exclude file, but
the order was swapped from the beginning. This belatedly fixes it.

* jc/gitignore-precedence:
  ignore: info/exclude should trump core.excludesfile

After "git add -N", the path appeared in output of "git diff HEAD"
and "git diff --cached HEAD", leading "git status" to classify it
as "Changes to be committed".  Such a path, however, is not yet to
be scheduled to be committed.  "git diff" showed the change to the
path as modification, not as a "new file", in the header of its
output.

Treat such paths as "yet to be added to the index but Git already
know about them"; "git diff HEAD" and "git diff --cached HEAD"
should not talk about them, and "git diff" should show them as new
files yet to be added to the index.

* nd/diff-i-t-a:
  diff-lib.c: adjust position of i-t-a entries in diff

The former seems to just be syntactic sugar for the latter.
And as it's sugar that AsciiDoctor doesn't understand, it
would be nice to avoid it. Since there are only two spots,
and the resulting source is not significantly harder to
read, it's worth doing.

Note that this does slightly affect the generated HTML (it
has an extra newline), but the rendered result for both HTML
and docbook should be the same (since the newline is not
syntactically significant there).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  Git 2.4.1

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

* sb/line-log-plug-pairdiff-leak:
  line-log.c: fix a memleak

* sb/test-bitmap-free-at-end:
  pack-bitmap.c: fix a memleak

Correct test bitrot.

* nd/t1509-chroot-test:
  t1509: update prepare script to be able to run t1509 in chroot again

"git cat-file bl $blob" failed to barf even though there is no
object type that is "bl".

* jk/type-from-string-gently:
  type_from_string_gently: make sure length matches

* ep/fix-test-lib-functions-report:
  test-lib-functions.sh: fix the second argument to some helper functions

Teach the codepaths that read .gitignore and .gitattributes files
that these files encoded in UTF-8 may have UTF-8 BOM marker at the
beginning; this makes it in line with what we do for configuration
files already.

* cn/bom-in-gitignore:
  attr: skip UTF8 BOM at the beginning of the input file
  config: use utf8_bom[] from utf.[ch] in git_parse_source()
  utf8-bom: introduce skip_utf8_bom() helper
  add_excludes_from_file: clarify the bom skipping logic
  dir: allow a BOM at the beginning of exclude files

Access to objects in repositories that borrow from another one on a
slow NFS server unnecessarily got more expensive due to recent code
becoming more cautious in a naive way not to lose objects to pruning.

* jk/prune-mtime:
  sha1_file: only freshen packs once per run
  sha1_file: freshen pack objects before loose
  reachable: only mark local objects as recent

We avoid setting core.worktree when the repository location is the
".git" directory directly at the top level of the working tree, but
the code misdetected the case in which the working tree is at the
root level of the filesystem (which arguably is a silly thing to
do, but still valid).

* jk/init-core-worktree-at-root:
  init: don't set core.worktree when initializing /.git

The DECORATE_SHORT_REFS option given to load_ref_decorations()
affects the way a copy of the refname is stored for each decorated
commit, and this forces later steps like current_pointed_by_HEAD()
to adjust their behaviour based on this initial settings.

Instead, we can always store the full refname and then shorten them
when producing the output.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous step to teach "log --decorate" to show "HEAD -> master"
instead of "HEAD, master" when showing the commit at the tip of the
'master' branch, when the 'master' branch is checked out, did not
work for "log --decorate=full".

The commands in the "log" family prepare commit decorations for all
refs upfront, and the actual string used in a decoration depends on
how load_ref_decorations() is called very early in the process.  By
default, "git log --decorate" stores names with common prefixes such
as "refs/heads" stripped; "git log --decorate=full" stores the full
refnames.

When the current_pointed_by_HEAD() function has to decide if "HEAD"
points at the branch a decoration describes, however, what was
passed to load_ref_decorations() to decide to strip (or keep) such a
common prefix is long lost.  This makes it impossible to reliably
tell if a decoration that stores "refs/heads/master", for example,
is the 'master' branch (under "--decorate" with prefix omitted) or
'refs/heads/master' branch (under "--decorate=full").

Keep what was passed to load_ref_decorations() in a global next to
the global variable name_decoration, and use that to decide how to
match what was read from "HEAD" and what is in a decoration.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>