commit: do not complain of empty messages from -C

When we pick another commit's message, we die() immediately
if we find that it's empty and we are not going to run an
editor (i.e., when running "-C" instead of "-c").  However,
this check is redundant and harmful.

It's redundant because we will already notice the empty
message later, after we would have run the editor, and die
there (just as we would for a regular, not "-C" case, where
the user provided an empty message in the editor).

It's harmful for a few reasons:

  1. It does not respect --allow-empty-message. As a result,
     a "git rebase -i" cannot "pick" such a commit. So you
     cannot even go back in time to fix it with a "reword"
     or "edit" instruction.

  2. It does not take into account other ways besides the
     editor to modify the message. For example, "git commit
     -C empty-commit -m foo" could take the author
     information from empty-commit, but add a message to it.
     There's more to do to make that work correctly (and
     right now we explicitly forbid "-C with -m"), but this
     removes one roadblock.

  3. The existing check is not enough to prevent segfaults.
     We try to find the "\n\n" header/body boundary in the
     commit. If it is at the end of the string (i.e., no
     body), _or_ if we cannot find it at all (i.e., a
     truncated commit object), we consider the message
     empty. With "-C", that's OK; we die in either case. But
     with "-c", we continue on, and in the case of a
     truncated commit may end up dereferencing NULL+2.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame: correctly handle files regardless of autocrlf.

If a file contained CRLF line endings in a repository with
core.autocrlf=input, then blame always marked lines as "Not Committed Yet",
even if they were unmodified.  Don't attempt to convert the line endings
when creating the fake commit so that blame works correctly regardless of
the autocrlf setting.

Reported-by: Ephrim Khong <dr.khong@gmail.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed along system libraries, such as MSysGit. In other words, the
assumption that curl-config is always installed was incorrect.

Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
to curl-config being missing), use the old behavior of falling back to
-lcurl.

Signed-off-by: Dave Borowitz <dborowitz@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
imap-send: use git-credential

git-imap-send was directly prompting for a password rather than
using git-credential. git-send-email, on the other hand, supports
git-credential.

This is a necessary improvement for users that use two factor
authentication, as they should not be expected to remember all of
their app specific passwords.

Signed-off-by: Dan Albert <danalbert@google.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame: large-scale performance rewrite

The previous implementation used a single sorted linear list of blame
entries for organizing all partial or completed work.  Every subtask had
to scan the whole list, with most entries not being relevant to the
task.  The resulting run-time was quadratic to the number of separate
chunks.

This change gives every subtask its own data to work with.  Subtasks are
organized into "struct origin" chains hanging off particular commits.
Commits are organized into a priority queue, processing them in commit
date order in order to keep most of the work affecting a particular blob
collated even in the presence of an extensive merge history.

For large files with a diversified history, a speedup by a factor of 3
or more is not unusual.

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/external-diff-use-argv-array' (early part)

Crash fix for codepath that miscounted the necessary size for an
array when spawning an external diff program.

* 'jk/external-diff-use-argv-array' (early part):
  run_external_diff: use an argv_array for the command line
Merge branch 'db/make-with-curl'

It turns out that some platforms do ship without curl-config even
though they build with the hardcoded default -lcurl and rely on it
to work.

* db/make-with-curl:
  Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR
Merge branch 'mk/doc-git-gui-display-untracked' into jch

* mk/doc-git-gui-display-untracked:
  Documentation: git-gui: describe gui.displayuntracked
Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into jch

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't put unsanitized branch names in $PS1
Merge branch 'km/git-svn-workaround-older-getopt-long' into jch

* km/git-svn-workaround-older-getopt-long:
  t9117: use --prefix "" instead of --prefix=""
Merge branch 'sk/tag-contains-wo-recursion' into jch

* sk/tag-contains-wo-recursion:
  git tag --contains: avoid stack overflow
Merge branch 'mw/symlinks' into jch

A finishing touch fix to a new change already in 'master'.

* mw/symlinks:
  setup: fix windows path buffer over-stepping
### keep in next
Merge branch 'ks/tree-diff-nway' into jch

Instead of running N pair-wise diff-trees when inspecting a
N-parent merge, find the set of paths that were touched by walking
N+1 trees in parallel.  These set of paths can then be turned into
N pair-wise diff-tree results to be processed through rename
detections and such.  And N=2 case nicely degenerates to the usual
2-way diff-tree, which is very nice.

* ks/tree-diff-nway:
  mingw: activate alloca
  combine-diff: speed it up, by using multiparent diff tree-walker directly
  tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
  Portable alloca for Git
  tree-diff: reuse base str(buf) memory on sub-tree recursion
  tree-diff: no need to call "full" diff_tree_sha1 from show_path()
  tree-diff: rework diff_tree interface to be sha1 based
  tree-diff: diff_tree() should now be static
  tree-diff: remove special-case diff-emitting code for empty-tree cases
  tree-diff: simplify tree_entry_pathcmp
  tree-diff: show_path prototype is not needed anymore
  tree-diff: rename compare_tree_entry -> tree_entry_pathcmp
  tree-diff: move all action-taking code out of compare_tree_entry()
  tree-diff: don't assume compare_tree_entry() returns -1,0,1
  tree-diff: consolidate code for emitting diffs and recursion in one place
  tree-diff: show_tree() is not needed
  tree-diff: no need to pass match to skip_uninteresting()
  tree-diff: no need to manually verify that there is no mode change for a path
  combine-diff: move changed-paths scanning logic into its own function
  combine-diff: move show_log_first logic/action out of paths scanning
Merge branch 'as/grep-fullname-config' into jch

Add a configuration variable to force --full-name to be default for
"git grep".

This may cause regressions on scripted users that do not expect
this new behaviour.

* as/grep-fullname-config:
  grep: add grep.fullName config variable
Merge branch 'jc/apply-ignore-whitespace' into jch

"--ignore-space-change" option of "git apply" ignored the
spaces at the beginning of line too aggressively, which is
inconsistent with the option of the same name "diff" and "git diff"
have.

* jc/apply-ignore-whitespace:
  apply --ignore-space-change: lines with and without leading whitespaces do not match
Merge branch 'mt/patch-id-stable' into jch

Introduce a new way to compute patch-id for a patch that is not
affected by the order of the paths that appear in the input.

This changes the generated patch-id unless the users add an extra
option to their command lines, but I deliberately queued the series
to 'next' without reverting that compatibility breakage to see if
people complain.  It could be that we do not have to worry about
the default flipping at all.  We'll see.

* mt/patch-id-stable:
  patch-id-test: test --stable and --unstable flags
  patch-id: document new behaviour
  patch-id: make it stable against hunk reordering
Merge branch 'mh/ref-transaction' into jch

Update "update-ref --stdin [-z]" and then introduce a transactional
support for (multi-)reference updates.

* mh/ref-transaction: (27 commits)
  ref_transaction_commit(): work with transaction->updates in place
  struct ref_update: add a type field
  struct ref_update: add a lock field
  ref_transaction_commit(): simplify code using temporary variables
  struct ref_update: store refname as a FLEX_ARRAY
  struct ref_update: rename field "ref_name" to "refname"
  refs: remove API function update_refs()
  update-ref --stdin: reimplement using reference transactions
  refs: add a concept of a reference transaction
  update-ref --stdin: harmonize error messages
  update-ref --stdin: improve the error message for unexpected EOF
  t1400: test one mistake at a time
  update-ref --stdin -z: deprecate interpreting the empty string as zeros
  update-ref.c: extract a new function, parse_next_sha1()
  t1400: test that stdin -z update treats empty <newvalue> as zeros
  update-ref --stdin: simplify error messages for missing oldvalues
  update-ref --stdin: make error messages more consistent
  update-ref --stdin: improve error messages for invalid values
  update-ref.c: extract a new function, parse_refname()
  parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice
  ...

# Conflicts:
# 	builtin/update-ref.c
Merge branch 'ym/fix-opportunistic-index-update-race' into jch

Read-only operations such as "git status" that internally refreshes
the index write out the refreshed index to the disk to optimize
future accesses to the working tree, but this could race with a
"read-write" operation that modify the index while it is running.
Detect such a race and avoid overwriting the index.

Duy raised a good point that we may need to do the same for the
normal writeout codepath, not just the "opportunistic" update
codepath.  While that is true, nobody sane would be running two
simultaneous operations that are clearly write-oriented competing
with each other against the same index file.  So in that sense that
can be done as a less urgent follow-up for this topic.

* ym/fix-opportunistic-index-update-race:
  read-cache.c: verify index file before we opportunistically update it
  wrapper.c: add xpread() similar to xread()

# Conflicts:
# 	cache.h
Merge branch 'nd/index-pack-one-fd-per-thread' into jch

Enable threaded index-pack on platforms without thread-unsafe
pread() emulation.

* nd/index-pack-one-fd-per-thread:
  index-pack: work around thread-unsafe pread()

# Conflicts:
# 	builtin/index-pack.c