Merge branch 'mh/write-refs-sooner-2.4' into maint

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

Merge branch 'mh/ref-directory-file' into maint

The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is
removed at the same time as 'refs/heads/xyzzy' is added (or vice
versa) very well.

* mh/ref-directory-file:
  reflog_expire(): integrate lock_ref_sha1_basic() errors into ours
  ref_transaction_commit(): delete extra "the" from error message
  ref_transaction_commit(): provide better error messages
  rename_ref(): integrate lock_ref_sha1_basic() errors into ours
  lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts
  lock_ref_sha1_basic(): report errors via a "struct strbuf *err"
  verify_refname_available(): report errors via a "struct strbuf *err"
  verify_refname_available(): rename function
  refs: check for D/F conflicts among refs created in a transaction
  ref_transaction_commit(): use a string_list for detecting duplicates
  is_refname_available(): use dirname in first loop
  struct nonmatching_ref_data: store a refname instead of a ref_entry
  report_refname_conflict(): inline function
  entry_matches(): inline function
  is_refname_available(): convert local variable "dirname" to strbuf
  is_refname_available(): avoid shadowing "dir" variable
  is_refname_available(): revamp the comments
  t1404: new tests of ref D/F conflicts within transactions

Merge branch 'mg/log-decorate-HEAD' into maint

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

Merge branch 'sb/t1020-cleanup' into maint

There was a commented-out (instead of being marked to expect
failure) test that documented a breakage that was fixed since the
test was written; turn it into a proper test.

* sb/t1020-cleanup:
  subdirectory tests: code cleanup, uncomment test

Merge branch 'jc/gitignore-precedence' into maint

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

Merge branch 'bc/connect-plink' into maint

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

Merge branch 'ph/rebase-i-redo' into maint

"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

Merge branch 'jk/add-e-kill-editor' into maint

"git add -e" did not allow the user to abort the operation by
killing the editor.

* jk/add-e-kill-editor:
  add: check return value of launch_editor

Merge branch 'mh/clone-verbosity-fix' into maint

Git 2.4 broke setting verbosity and progress levels on "git clone"
with native transports.

* mh/clone-verbosity-fix:
  clone: call transport_set_verbosity before anything else on the newly created transport

Merge branch 'jk/sha1-file-reduce-useless-warnings' into maint

* jk/sha1-file-reduce-useless-warnings:
  sha1_file: squelch "packfile cannot be accessed" warnings

Merge branch 'tb/blame-resurrect-convert-to-git' into maint

Some time ago, "git blame" (incorrectly) lost the convert_to_git()
call when synthesizing a fake "tip" commit that represents the
state in the working tree, which broke folks who record the history
with LF line ending to make their project portabile across
platforms while terminating lines in their working tree files with
CRLF for their platform.

* tb/blame-resurrect-convert-to-git:
  blame: CRLF in the working tree and LF in the repo

Merge branch 'jc/plug-fmt-merge-msg-leak' into maint

* jc/plug-fmt-merge-msg-leak:
  fmt-merge-msg: plug small leak of commit buffer

Merge branch 'pt/xdg-config-path' into maint

Code clean-up for xdg configuration path support.

* pt/xdg-config-path:
  path.c: remove home_config_paths()
  git-config: replace use of home_config_paths()
  git-commit: replace use of home_config_paths()
  credential-store.c: replace home_config_paths() with xdg_config_home()
  dir.c: replace home_config_paths() with xdg_config_home()
  attr.c: replace home_config_paths() with xdg_config_home()
  path.c: implement xdg_config_home()
  t0302: "unreadable" test needs POSIXPERM
  t0302: test credential-store support for XDG_CONFIG_HOME
  git-credential-store: support XDG_CONFIG_HOME
  git-credential-store: support multiple credential files

ll-merge: pass the original path to external drivers

The interface to custom low-level merge driver was modeled to be
capable of driving programs like "merge" (from the RCS suite) that
can produce result solely by looking at three files that hold
contents of common ancestor, ours and theirs.  The information we
feed to the external drivers via the command line placeholders %O,
%A, and %B were designed to be purely about contents by giving
names of the temporary files that hold these variants without
exposing the original pathname.  No matter where the result goes,
merging the same three variants should produce the same result,
contents is the king, that is the Git way.

The external driver interface, however, is meant to help people to
step outside the Git worldview, and sometimes people want to know
the final path that the resulting merged contents would be stored
in.  Expose this to the external drivers via a new placeholder %P.

Requested-by: Andreas Gondek
Signed-off-by: Junio C Hamano <redacted>

git-am: add am.threeWay config variable

Add the am.threeWay configuration variable to use the -3 or --3way
option of git am by default. When am.threeway is set and not desired
for a specific git am command, the --no-3way option can be used to
override it.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Junio C Hamano <redacted>

t4150-am: refactor am -3 tests

Create a setup for git am -3 in a separate test instead of creating
this setup each time.

This prepares for the next commit which will use this setup as well.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-am.sh: fix initialization of the threeway variable

Initialization for the threeway variable was missing. This caused
a behavior change for command lines like:

threeway=t git am ...

This commit adds initialization for this variable.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Junio C Hamano <redacted>

index-pack: fix truncation of off_t in comparison

Commit c6458e6 (index-pack: kill union delta_base to save
memory, 2015-04-18) refactored the comparison functions used
in sorting and binary searching our delta list. The
resulting code does something like:

  int cmp_offsets(off_t a, off_t b)
  {
  return a - b;
  }

This works most of the time, but produces nonsensical
results when the difference between the two offsets is
larger than what can be stored in an "int". This can lead to
unresolved deltas if the packsize is larger than 2G (even on
64-bit systems, an int is still typically 32 bits):

  $ git clone git://github.com/mozilla/gecko-dev
  Cloning into 'gecko-dev'...
  remote: Counting objects: 4800161, done.
  remote: Compressing objects: 100% (178/178), done.
  remote: Total 4800161 (delta 88), reused 0 (delta 0), pack-reused 4799978
  Receiving objects: 100% (4800161/4800161), 2.21 GiB | 3.26 MiB/s, done.
  Resolving deltas:  99% (3808820/3811944), completed with 0 local objects.
  fatal: pack has 3124 unresolved deltas
  fatal: index-pack failed

We can fix it by doing direct comparisons between the
offsets and returning constants; the callers only care about
the sign of the comparison, not the magnitude.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

read_loose_refs(): simplify function logic

Make it clearer that there are two possible ways to read the
reference, but that we handle read errors uniformly regardless of
which way it was read.

This refactoring also makes the following change easier to implement.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

configure: add getdelim() check

As an optimization, strbuf will take advantage of getdelim() if
available, so add a configure check which defines HAVE_GETDELIM if
found.

Signed-off-by: Eric Sunshine <redacted>
Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

config.mak.uname: Darwin: define HAVE_GETDELIM for modern OS X releases

On Mac OS X, getdelim() first became available with Xcode 4.1[1], which
was released the same day as OS X 10.7 "Lion", so assume getdelim()
availability from 10.7 onward. (As of this writing, OS X is at 10.10
"Yosemite".)

According to Wikipedia[2], 4.1 was also available for download by paying
developers on OS X 10.6 "Snow Leopard", so it's possible that some 10.6
machines may have getdelim(). However, as strbuf's use of getdelim() is
purely an optimization, let's be conservative and assume 10.6 and
earlier lack getdelim().

[1]: Or, possibly with Xcode 4.0, but that version is no longer
     available for download, or not available to non-paying developers,
     so testing is not possible.

[2]: http://en.wikipedia.org/wiki/Xcode

Helped-by: Jeff King <redacted>
Signed-off-by: Eric Sunshine <redacted>
Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

ewah: use less generic macro name

The ewah/ewok.h header pollutes the global namespace with
"BITS_IN_WORD", without any specific notion that we are
talking about the bits in an eword_t. We can give this the
more specific name "BITS_IN_EWORD".

Signed-off-by: Jeff King <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

ewah/bitmap: silence warning about MASK macro redefinition

On PowerPC Mac OS X (10.5.8 "Leopard" with Xcode 3.1),
system header /usr/include/ppc/param.h[1] pollutes the
preprocessor namespace with a macro generically named MASK.
This conflicts with the same-named macro in ewah/bitmap.c.
We can avoid this conflict by using a more specific name.

[1]: Included indirectly via:
     git-compat-util.h ->
     sys/sysctl.h ->
     sys/ucred.h ->
     sys/param.h ->
     machine/param.h ->
     ppc/param.h

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/technical/pack-protocol: mention http as possible protocol

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

pull: use git-rev-parse --parseopt for option parsing

To enable unambiguous parsing of abbreviated options, bundled short
options, separate form options and to provide consistent usage help, use
git-rev-parse --parseopt for option parsing. With this, simplify the
option parsing code.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

pull: handle git-fetch's options as well

While parsing the command-line arguments, git-pull stops parsing at the
first unrecognized option, assuming that any subsequent options are for
git-fetch, and can thus be kept in the shell's positional parameters
list, so that it can be passed to git-fetch via the expansion of "$@".

However, certain functions in git-pull assume that the positional
parameters do not contain any options:

* error_on_no_merge_candidates() uses the number of positional
  parameters to determine which error message to print out, and will
  thus print the wrong message if git-fetch's options are passed in as
  well.

* the call to get_remote_merge_branch() assumes that the positional
  parameters only contains the optional repo and refspecs, and will
  thus silently fail if git-fetch's options are passed in as well.

* --dry-run is a valid git-fetch option, but if provided after any
  git-fetch options, it is not recognized by git-pull and thus git-pull
  will continue to run the merge or rebase.

Fix these bugs by teaching git-pull to parse git-fetch's options as
well. Add tests to prevent regressions.

This removes the limitation where git-fetch's options have to come after
git-merge's and git-rebase's options on the command line. Update the
documentation to reflect this.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'pt/pull-tests' into pt/pull-optparse

* pt/pull-tests:
  t5520: check reflog action in fast-forward merge
  t5521: test --dry-run does not make any changes
  t5520: test --rebase failure on unborn branch with index
  t5520: test --rebase with multiple branches
  t5520: test work tree fast-forward when fetch updates head
  t5520: test for failure if index has unresolved entries
  t5520: test no merge candidates cases
  t5520: prevent field splitting in content comparisons

for-each-ref: report broken references correctly

If there is a loose reference file with invalid contents, "git
for-each-ref" incorrectly reports the problem as being a missing
object with name NULL_SHA1:

    $ echo '12345678' >.git/refs/heads/nonsense
    $ git for-each-ref
    fatal: missing object 0000000000000000000000000000000000000000 for refs/heads/nonsense

With an explicit "--format" string, it can even report that the
reference validly points at NULL_SHA1:

    $ git for-each-ref --format='%(objectname) %(refname)'
    0000000000000000000000000000000000000000 refs/heads/nonsense
    $ echo $?
    0

This has been broken since

    b7dd2d2 for-each-ref: Do not lookup objects when they will not be used (2009-05-27)

, which changed for-each-ref from using for_each_ref() to using
git_for_each_rawref() in order to avoid looking up the referred-to
objects unnecessarily. (When "git for-each-ref" is given a "--format"
string that doesn't include information about the pointed-to object,
it does not look up the object at all, which makes it considerably
faster. Iterating with DO_FOR_EACH_INCLUDE_BROKEN is essential to this
optimization because otherwise for_each_ref() would itself need to
check whether the object exists as part of its brokenness test.)

But for_each_rawref() includes broken references in the iteration, and
"git for-each-ref" doesn't itself reject references with REF_ISBROKEN.
The result is that broken references are processed *as if* they had
the value NULL_SHA1, which is the value stored in entries for broken
references.

Change "git for-each-ref" to emit warnings for references that are
REF_ISBROKEN but to otherwise skip them.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6301: new tests of for-each-ref error handling

Add tests that for-each-ref correctly reports broken loose reference
files and references that point at missing objects. In fact, two of
these tests fail, because (1) NULL_SHA1 is not recognized as an
invalid reference value, and (2) for-each-ref doesn't respect
REF_ISBROKEN. Fixes to come.

Note that when for-each-ref is run with a --format option that doesn't
require the object to be looked up, then we should still notice if a
loose reference file is corrupt or contains NULL_SHA1, but we don't
notice if it points at a missing object because we don't do an object
lookup. This is OK.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: do not feed tags to clear_commit_marks()

"git format-patch --ignore-if-in-upstream A..B", when either A or B
is a tag, failed miserably.

This is because the code passes the tips it used for traversal to
clear_commit_marks(), after running a temporary revision traversal
to enumerate the commits on both branches to find if they have
commits that make equivalent changes.  The revision traversal
machinery knows how to enumerate commits reachable starting from a
tag, but clear_commit_marks() wants to take nothing but a commit.

In the longer term, it might be a more correct fix to teach
clear_commit_marks() to do the same "committish to commit"
dereferencing that is done in the revision traversal machinery,
but for now this fix should suffice.

Reported-by: Bruce Korb <redacted>
Helped-by: Christian Couder <redacted>
Helped-by: brian m. carlson <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: further warn about unsupported sendmail aliases features

The sendmail aliases parser diagnoses unsupported features and
unrecognized lines. For completeness, also warn about unsupported
redirection to "/path/name" and "|command", as well as ":include:".

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001: add sendmail aliases line continuation tests

A line beginning with whitespace is folded into the preceding line.
A line ending with '\' consumes the following line.

While here, also test an empty sendmail aliases file.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001: refactor sendmail aliases test infrastructure

Several new tests of sendmail aliases parsing will be added in a
subsequent patch, so factor out functionality common to all of them
into a new helper function.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: implement sendmail aliases line continuation support

Logical lines in sendmail aliases files can be spread over multiple
physical lines[1]. A line beginning with whitespace is folded into the
preceding line. A line ending with '\' consumes the following line.

[1]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: simplify sendmail aliases comment and blank line recognizer

Replace unnecessarily complex regular expression for recognizing comment
and blank lines in sendmail aliases with idiomatic expressions which
can be easily understood at a glance.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: refactor sendmail aliases parser

The sendmail aliases parser inlined into %parse_alias is already
uncomfortably large and is expected to grow as additional functionality
is implemented, so extract it to improve manageability.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: fix style: cuddle 'elsif' and 'else' with closing brace

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: drop noise comments which merely repeat what code says

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: visually distinguish sendmail aliases parser warnings

Although emitted to stderr, warnings from the sendmail aliases parser
are not visually distinguished as such, and thus can easily be
overlooked in the normal noisy send-email output.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: further document missing sendmail aliases functionality

Sendmail aliases[1] supports expansion to a file ("/path/name") or
pipe ("|command"), as well as file inclusion (":include: /path/name"),
however, our implementation does not support such functionality.

[1]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

blame: add blame.showEmail configuration

Complement existing --show-email option with fallback
configuration variable, with tests.

Signed-off-by: Quentin Neill <redacted>
Signed-off-by: Junio C Hamano <redacted>

Sixth batch for 2.5 cycle

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'sb/test-bitmap-free-at-end'

An earlier leakfix to bitmap testing code was incomplete.

* sb/test-bitmap-free-at-end:
  test_bitmap_walk: free bitmap with bitmap_free

Merge branch 'mm/rebase-i-post-rewrite-exec'

"git rebase -i" fired post-rewrite hook when it shouldn't (namely,
when it was told to stop sequencing with 'exec' insn).

* mm/rebase-i-post-rewrite-exec:
  t5407: use <<- to align the expected output
  rebase -i: fix post-rewrite hook with failed exec command
  rebase -i: demonstrate incorrect behavior of post-rewrite

Merge branch 'fm/fetch-raw-sha1'

"git upload-pack" that serves "git fetch" can be told to serve
commits that are not at the tip of any ref, as long as they are
reachable from a ref, with uploadpack.allowReachableSHA1InWant
configuration variable.

* fm/fetch-raw-sha1:
  upload-pack: optionally allow fetching reachable sha1
  upload-pack: prepare to extend allow-tip-sha1-in-want
  config.txt: clarify allowTipSHA1InWant with camelCase

Merge branch 'sg/help-group'

Group list of commands shown by "git help" along the workflow
elements to help early learners.

* sg/help-group:
  help: respect new common command grouping
  command-list.txt: drop the "common" tag
  generate-cmdlist: parse common group commands
  command-list.txt: add the common groups block
  command-list: prepare machinery for upcoming "common groups" section

Merge branch 'mm/log-format-raw-doc'

Clarify that "log --raw" and "log --format=raw" are unrelated
concepts.

* mm/log-format-raw-doc:
  Documentation/log: clarify sha1 non-abbreviation in log --raw
  Documentation/log: clarify what --raw means

Merge branch 'dt/cat-file-follow-symlinks'

"git cat-file --batch(-check)" learned the "--follow-symlinks"
option that follows an in-tree symbolic link when asked about an
object via extended SHA-1 syntax, e.g. HEAD:RelNotes that points at
Documentation/RelNotes/2.5.0.txt.  With the new option, the command
behaves as if HEAD:Documentation/RelNotes/2.5.0.txt was given as
input instead.

* dt/cat-file-follow-symlinks:
  cat-file: add --follow-symlinks to --batch
  sha1_name: get_sha1_with_context learns to follow symlinks
  tree-walk: learn get_tree_entry_follow_symlinks

Merge branch 'rs/janitorial'

Code clean-up.

* rs/janitorial:
  dir: remove unused variable sb
  clean: remove unused variable buf
  use file_exists() to check if a file exists in the worktree

Merge branch 'jk/stash-options'

Make "git stash something --help" error out, so that users can
safely say "git stash drop --help".

* jk/stash-options:
  stash: recognize "--help" for subcommands
  stash: complain about unknown flags

Merge branch 'da/mergetool-winmerge'

"git mergetool" learned to drive WinMerge as a backend.

* da/mergetool-winmerge:
  mergetools: add winmerge as a builtin tool
  mergetool--lib: set IFS for difftool and mergetool

Merge branch 'mc/commit-doc-grammofix'

Doc grammar fix.

* mc/commit-doc-grammofix:
  Documentation/git-commit: grammofix

Merge branch 'jh/filter-empty-contents'

The clean/smudge interface did not work well when filtering an
empty contents (failed and then passed the empty input through).
It can be argued that a filter that produces anything but empty for
an empty input is nonsense, but if the user wants to do strange
things, then why not?

* jh/filter-empty-contents:
  sha1_file: pass empty buffer to index empty file

Merge branch 'ah/usage-strings'

A few usage string updates.

* ah/usage-strings:
  blame, log: format usage strings similarly to those in documentation

Merge branch 'jk/http-backend-deadlock'

Communication between the HTTP server and http_backend process can
lead to a dead-lock when relaying a large ref negotiation request.
Diagnose the situation better, and mitigate it by reading such a
request first into core (to a reasonable limit).

* jk/http-backend-deadlock:
  http-backend: spool ref negotiation requests to buffer
  t5551: factor out tag creation
  http-backend: fix die recursion with custom handler

Merge branch 'dt/clean-pathspec-filter-then-lstat'

"git clean pathspec..." tried to lstat(2) and complain even for
paths outside the given pathspec.

* dt/clean-pathspec-filter-then-lstat:
  clean: only lstat files in pathspec

apply: reject a hunk that does not do anything

A hunk like this in a hand-edited patch without correctly adjusting
the line counts:

     @@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
             auth = (struct ieee80211_authentication *)
                     skb_put(skb, sizeof(struct ieee80211_authentication));
     -       some old text
     +       some new text
     --
     2.1.0

     dev mailing list

at the end of the input does not have a good way for us to diagnose
it as a corrupt patch.  We just read two context lines and discard
the remainder as cruft, which we must do in order to ignore the
e-mail footer.  Notice that the patch does not change anything and
signal an error.

Note that this fix will not help if the hand-edited hunk header were
"@@ -660,3, +660,2" to include the removal.  We would just remove
the old text without adding the new one, and treat "+ some new text"
and everything after that line as trailing cruft.  So it is dubious
that this patch alone would help very much in practice, but it may
be better than nothing.

Signed-off-by: Junio C Hamano <redacted>

suppress errors on missing UNINTERESTING links

When we are traversing commit parents along the
UNINTERESTING side of a revision walk, we do not care if
the parent turns out to be missing. That lets us limit
traversals using unreachable and possibly incomplete
sections of history. However, we do still print error
messages about the missing commits; this patch suppresses
the error, as well.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

silence broken link warnings with revs->ignore_missing_links

We set revs->ignore_missing_links to instruct the
revision-walking machinery that we know the history graph
may be incomplete. For example, we use it when walking
unreachable but recent objects; we want to add what we can,
but it's OK if the history is incomplete.

However, we still print error messages for the missing
objects, which can be confusing. This is not an error, but
just a normal situation when transitioning from a repository
last pruned by an older git (which can leave broken segments
of history) to a more recent one (where we try to preserve
whole reachable segments).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

add quieter versions of parse_{tree,commit}

When we call parse_commit, it will complain to stderr if the
object does not exist or cannot be read. This means that we
may produce useless error messages if this situation is
expected (e.g., because the object is marked UNINTERESTING,
or because revs->ignore_missing_links is set).

We can fix this by adding a new "parse_X_gently" form that
takes a flag to suppress the messages. The existing
"parse_X" form is already gentle in the sense that it
returns an error rather than dying, and we could in theory
just add a "quiet" flag to it (with existing callers passing
"0"). But doing it this way means we do not have to disturb
existing callers.

Note also that the new flag is "quiet_on_missing", and not
just "quiet". We could add a flag to suppress _all_ errors,
but besides being a more invasive change (we would have to
pass the flag down to sub-functions, too), there is a good
reason not to: we would never want to use it. Missing a
linked object is expected in some circumstances, but it is
never expected to have a malformed commit, or to get a tree
when we wanted a commit.  We should always complain about
these corruptions.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

completion: suggest sequencer commands for revert

Signed-off-by: Thomas Braun <redacted>
Acked-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

glossary: add "remote", "submodule", "superproject"

Noticed-by: Philip Oakley <redacted>
Helped-by: Junio C Hamano <redacted>
Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

setup_git_directory: delay core.bare/core.worktree errors

If both core.bare and core.worktree are set, we complain
about the bogus config and die. Dying is good, because it
avoids commands running and doing damage in a potentially
incorrect setup. But dying _there_ is bad, because it means
that commands which do not even care about the work tree
cannot run. This can make repairing the situation harder:

  [setup]
  $ git config core.bare true
  $ git config core.worktree /some/path

  [OK, expected.]
  $ git status
  fatal: core.bare and core.worktree do not make sense

  [Hrm...]
  $ git config --unset core.worktree
  fatal: core.bare and core.worktree do not make sense

  [Nope...]
  $ git config --edit
  fatal: core.bare and core.worktree do not make sense

  [Gaaah.]
  $ git help config
  fatal: core.bare and core.worktree do not make sense

Instead, let's issue a warning about the bogus config when
we notice it (i.e., for all commands), but only die when the
command tries to use the work tree (by calling setup_work_tree).
So we now get:

  $ git status
  warning: core.bare and core.worktree do not make sense
  fatal: unable to set up work tree using invalid config

  $ git config --unset core.worktree
  warning: core.bare and core.worktree do not make sense

We have to update t1510 to accomodate this; it uses
symbolic-ref to check whether the configuration works or
not, but of course that command does not use the working
tree. Instead, we switch it to use `git status`, as it
requires a work-tree, does not need any special setup, and
is read-only (so a failure will not adversely affect further
tests).

In addition, we add a new test that checks the desired
behavior (i.e., that running "git config" with the bogus
config does in fact work).

Reported-by: SZEDER Gábor <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: silence perl/PM.stamp recipe

Every time we run "make", we update perl/PM.stamp, which
contains a list of all of the perl module files (if it's
updated, we need to rebuild perl/perl.mak, since the
Makefile will not otherwise know about the new files).

This means that every time "make" is run, we see:

      GEN perl/PM.stamp

in the output, even though it is not likely to have changed.
Let's make this recipe completely silent, as we do for other
auto-generated dependency files (e.g., GIT-CFLAGS).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS

We force the GIT-BUILD-OPTIONS recipe to run every time
"make" is invoked. We must do this to catch new options
which may have come from the command-line or environment.

However, we actually update the file's timestamp each time
the recipe is run, whether anything changed or not. As a
result, any files which depend on it (for example, all of
the perl scripts, which need to know whether NO_PERL was
set) will be re-built every time.

Let's do our usual trick of writing to a tempfile, then
doing a "cmp || mv" to update the file only when something
changed.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: drop dependency between git-instaweb and gitweb

The rule for "git-instaweb" depends on "gitweb". This makes
no sense, because:

  1. git-instaweb has no build-time dependency on gitweb; it
     is a run-time dependency

  2. gitweb is a directory that we want to recursively make
     in. As a result, its recipe is marked .PHONY, which
     causes "make" to rebuild git-instaweb every time it is
     run.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5520: check reflog action in fast-forward merge

When testing a fast-forward merge with git-pull, check to see if the
reflog action is "pull" with the arguments passed to git-pull.

While we are in the vicinity, remove the empty line as well.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5521: test --dry-run does not make any changes

Test that when --dry-run is provided to git-pull, it does not make any
changes, namely:

* --dry-run gets passed to git-fetch, so no FETCH_HEAD will be created
  and no refs will be fetched.

* The index and work tree will not be modified.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5520: test --rebase failure on unborn branch with index

Commit 19a7fcb (allow pull --rebase on branch yet to be born,
2009-08-11) special cases git-pull on an unborn branch in a different
code path such that git-pull --rebase is still valid even though there
is no HEAD yet.

This code path still ensures that there is no index in order not to lose
any staged changes. Implement a test to ensure that this check is
triggered.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5520: test --rebase with multiple branches

Since rebasing on top of multiple upstream branches does not make sense,
since 51b2ead (disallow providing multiple upstream branches to rebase,
pull --rebase, 2009-02-18), git-pull explicitly disallowed specifying
multiple branches in the rebase case.

Implement tests to ensure that git-pull fails and prints out the
user-friendly error message in such a case.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5520: test work tree fast-forward when fetch updates head

Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.

Implement tests to ensure that the fast-forward occurs in such a case,
as well as to ensure that the user-friendly advice is printed upon
failure.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5520: test for failure if index has unresolved entries

Commit d38a30d (Be more user-friendly when refusing to do something
because of conflict., 2010-01-12) introduced code paths to git-pull
which will error out with user-friendly advices if the user is in the
middle of a merge or has unmerged files.

Implement tests to ensure that git-pull will not run, and will print
these advices, if the user is in the middle of a merge or has unmerged
files in the index.

Signed-off-by: Paul Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

submodule doc: reorder introductory paragraphs

It's better to start the man page with a description of what
submodules actually are, instead of saying what they are not.

Reorder the paragraphs such that

 - the first short paragraph introduces the submodule concept,
 - the second paragraph highlights the usage of the submodule command,
 - the third paragraph giving background information, and finally
 - the fourth paragraph discusing alternatives such as subtrees and
   remotes, which we don't want to be confused with.

This ordering deepens the knowledge on submodules with each paragraph.
First the basic questions like "How/what" will be answered, while the
underlying concepts will be taught at a later time.

Making sure it is not confused with subtrees and remotes is not really
enhancing knowledge of submodules itself, but rather painting the big
picture of git concepts, so you could also argue to have it as the second
paragraph. Personally I think this may confuse readers, specially
newcomers though.

Additionally to reordering the paragraphs, they have been slightly
reworded.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: include 'merge.branchdesc' for merge and config as well

'merge.branchdesc' is only mentioned in the docs of 'git fmt-merge-msg'.

The description of 'merge.log' is already duplicated between
'merge-config.txt' and 'git-fmt-merge-msg.txt'; instead of duplicating the
description of another config variable, extract the descriptions of both
of these variables from 'git-fmt-merge-msg.txt' into a separate file and
include it there and in 'merge-config.txt'.

Leave 'merge.summary' only in git-fmt-merge-msg.txt, as it is marked
as deprecated.

Signed-off-by: SZEDER Gábor <redacted>
Signed-off-by: Junio C Hamano <redacted>

xmmap(): drop "Out of memory?"

We show that message with die_errno(), but the OS is ought to know
why mmap(2) failed much better than we do.  There is no reason for
us to say "Out of memory?" here.

Signed-off-by: Junio C Hamano <redacted>

config.c: rewrite ENODEV into EISDIR when mmap fails

If we try to mmap a directory, we'll get ENODEV. This
translates to "no such device" for the user, which is not
very helpful. Since we've just fstat()'d the file, we can
easily check whether the problem was a directory to give a
better message.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

config.c: avoid xmmap error messages

The config-writing code uses xmmap to map the existing
config file, which will die if the map fails. This has two
downsides:

  1. The error message is not very helpful, as it lacks any
     context about the file we are mapping:

       $ mkdir foo
       $ git config --file=foo some.key value
       fatal: Out of memory? mmap failed: No such device

  2. We normally do not die in this code path; instead, we'd
     rather report the error and return an appropriate exit
     status (which is part of the public interface
     documented in git-config.1).

This patch introduces a "gentle" form of xmmap which lets us
produce our own error message. We do not want to use mmap
directly, because we would like to use the other
compatibility elements of xmmap (e.g., handling 0-length
maps portably).

The end result is:

    $ git.compile config --file=foo some.key value
    error: unable to mmap 'foo': No such device
    $ echo $?
    3

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

config.c: fix mmap leak when writing config

We mmap the existing config file, but fail to unmap it if we
hit an error. The function already has a shared exit path,
so we can fix this by moving the mmap pointer to the
function scope and clearing it in the shared exit.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

read-cache.c: drop PROT_WRITE from mmap of index

Once upon a time, git's in-memory representation of a cache
entry actually pointed to the mmap'd on-disk data. So in
520fc24 (Allow writing to the private index file mapping.,
2005-04-26), we specified PROT_WRITE so that we could tweak
the entries while we run (in our own MAP_PRIVATE copy-on-write
version, of course).

Later, 7a51ed6 (Make on-disk index representation separate
from in-core one, 2008-01-14) stopped doing this; we copy
the data into our in-core representation, and then drop the
mmap immediately. We can therefore drop the PROT_WRITE flag.
It's probably not hurting anything as it is, but it's
potentially confusing.

Note that we could also mark the mapping as "const" to
verify that we never write to it. However, we don't
typically do that for our other maps, as it then requires
casting to munmap() it.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

p4: retrieve the right revision of the file in UTF-16 codepath

Fixing bug with UTF-16 files when they are retrieved by git-p4.  It
was always getting the tip version of the file and the history of
the file was lost.

Signed-off-by: Miguel Torroja <redacted>
Acked-by: Luke Diamand <redacted>
Signed-off-by: Junio C Hamano <redacted>

ref_transaction_commit(): do not capitalize error messages

Our convention is for error messages to start with a lower-case
letter.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

verify_lock(): do not capitalize error messages

Our convention is for error messages to start with a lower-case
letter.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

verify_lock(): report errors via a strbuf

Instead of writing error messages directly to stderr, write them to
a "strbuf *err".  The caller, lock_ref_sha1_basic(), uses this error
reporting convention with all the other callees, and reports its
error this way to its callers.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT

The latter is a much more descriptive name (and we support
"color.diff.context" now). This also updates the name of any
local variables which were used to store the color.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: accept color.diff.context as a synonym for "plain"

The term "plain" is a bit ambiguous; let's allow the more
specific "context", but keep "plain" around for
compatibility.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'nd/untracked-cache'

* nd/untracked-cache:
  t7063: hide stderr from setup inside prereq

t7063: hide stderr from setup inside prereq

When t7063 starts, it runs "update-index --untracked-cache"
to see if we support the untracked cache. Its output goes
straight to stderr, even if the test is not run with "-v".
Let's wrap it in a prereq that will hide the output by
default, but show it with "-v".

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001: write $HOME/, not ~/, to help shells without tilde expansion

Even though it is in POSIX, we do not have to use it, only to hurt
shells that may lack the support.

The .mailrc test tries to define an alias in .mailrc in the home
directory by shell redirection, and then tries to see ~/.mailrc in
config is tilde-expanded by Git without help from shell.  So the
creation should become $HOME/ to be portable for shells that may
lack tilde expansion but the reference should be done as "~/.mailrc".

Signed-off-by: Junio C Hamano <redacted>

send-email: add sendmail email aliases format

Teach send-email to read aliases in the sendmail aliases format, i.e.

<alias>: <address|alias>[, <address|alias>...]

Examples:

alice: Alice W Land <redacted>
bob: Robert Bobbyton <redacted>
# this is a comment
   # this is also a comment
chloe: chloe@example.com
abgroup: alice, bob
bcgrp: bob, chloe, Other <redacted>

 - Quoted aliases and quoted addresses are not supported.
 - Line continuations are not supported.

Warnings are printed for explicitly unsupported constructs, and any
other lines that are not matched by the parser.

Signed-off-by: Allen Hubbe <redacted>
Signed-off-by: Junio C Hamano <redacted>

verify_lock(): on errors, let the caller unlock the lock

The caller already knows how to do it, so always do it in the same
place.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

verify_lock(): return 0/-1 rather than struct ref_lock *

Its return value wasn't conveying any extra information, but it made
the reader wonder whether the ref_lock that it returned might be
different than the one that was passed to it. So change the function
to the traditional "return 0 on success or a negative value on error".

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

clone: reorder --dissociate and --reference options

These options are intimately related, so it makes sense to
list them nearby in the "-h" output (they are already
adjacent in the manpage).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

clone: use OPT_STRING_LIST for --reference

Not only does this save us having to implement a custom
callback, but it handles "--no-reference" in the usual way
(to clear the list).

The generic callback does copy the string, which we don't
technically need, but that should not hurt anything.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff.c: --ws-error-highlight=<kind> option

Traditionally, we only cared about whitespace breakages introduced
in new lines.  Some people want to paint whitespace breakages on old
lines, too.  When they see a whitespace breakage on a new line, they
can spot the same kind of whitespace breakage on the corresponding
old line and want to say "Ah, those breakages are there but they
were inherited from the original, so let's not touch them for now."

Introduce `--ws-error-highlight=<kind>` option, that lets them pass
a comma separated list of `old`, `new`, and `context` to specify
what lines to highlight whitespace errors on.

Signed-off-by: Junio C Hamano <redacted>

diff.c: add emit_del_line() and emit_context_line()

Traditionally, we only had emit_add_line() helper, which knows how
to find and paint whitespace breakages on the given line, because we
only care about whitespace breakages introduced in new lines.  The
context lines and old (i.e. deleted) lines are emitted with a
simpler emit_line_0() that paints the entire line in plain or old
colors.

Identify callers of emit_line_0() that show deleted lines and
context lines, have them call new helpers, emit_del_line() and
emit_context_line(), so that we can later tweak what is done to
these two classes of lines.

Signed-off-by: Junio C Hamano <redacted>

Sync with 2.4.2

Git 2.4.2

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/still-interesting' into maint

"git rev-list --objects $old --not --all" to see if everything that
is reachable from $old is already connected to the existing refs
was very inefficient.

* jk/still-interesting:
  limit_list: avoid quadratic behavior from still_interesting

Merge branch 'jc/hash-object' into maint

"hash-object --literally" introduced in v2.2 was not prepared to
take a really long object type name.

* jc/hash-object:
  write_sha1_file(): do not use a separate sha1[] array
  t1007: add hash-object --literally tests
  hash-object --literally: fix buffer overrun with extra-long object type
  git-hash-object.txt: document --literally option

Merge branch 'jk/rebase-quiet-noop' into maint

"git rebase --quiet" was not quite quiet when there is nothing to
do.

* jk/rebase-quiet-noop:
  rebase: silence "git checkout" for noop rebase