add--interactive: ignore unmerged entries in patch mode

When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").

The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.

We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field.  Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Highlight interesting parts of diff

Reading diff output is sometimes very hard, even if it's colored,
especially if lines differ only in few characters.  This is often true
when a commit fixes a typo or renames some variables or functions.

This commit teaches gitweb to highlight characters that are different
between old and new line with a light green/red background.  This should
work in the similar manner as in Trac or GitHub.

The algorithm that compares lines is based on contrib/diff-highlight.
Basically, it works by determining common prefix/suffix of corresponding
lines and highlightning only the middle part of lines.  For more
information, see contrib/diff-highlight/README.

Combined diffs are not supported but a following commit will change it.

Since we need to pass esc_html()'ed or esc_html_hl_regions()'ed lines to
format_diff_lines(), so it was taught to accept preformatted lines
passed as a reference.

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Refinement highlightning in combined diffs

The highlightning of combined diffs is currently disabled.  This is
because output from a combined diff is much harder to highlight because
it is not obvious which removed and added lines should be compared.

Current code requires that the number of added lines is equal to the
number of removed lines and only skips first +/- character, treating
second +/- as a line content, Thus, it is not possible to simply use
existing algorithm unchanged for combined diffs.

Let's start with a simple case: only highlight changes that come from
one parent, i.e. when every removed line has a corresponding added line
for the same parent.  This way the highlightning cannot get wrong. For
example, following diffs would be highlighted:

	- removed line for first parent
	+ added line for first parent
	  context line
	 -removed line for second parent
	 +added line for second parent

or

	- removed line for first parent
	 -removed line for second parent
	+ added line for first parent
	 +added line for second parent

but following output will not:

	- removed line for first parent
	 -removed line for second parent
	 +added line for second parent
	++added line for both parents

In other words, we require that pattern of '-'-es in pre-image matches
pattern of '+'-es in post-image.

Further changes may introduce more intelligent approach that better
handles combined diffs.

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: error out when the "upstream" semantics does not make sense

The user can say "git push" without specifying any refspec.  When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.

However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:

 - The current branch does not have branch.$name.remote configured.  By
   definition, "git push" that does not name where to push to will not
   know where to push to.  The user may explicitly say "git push $there",
   but again, by definition, no branch at repository $there is set to
   integrate with the current branch in this case and we wouldn't know
   which remote branch to update.

 - The current branch does have branch.$name.remote configured, but it
   does not specify branch.$name.merge that names what branch at the
   remote this branch integrates with. "git push" knows where to push in
   this case (or the user may explicitly say "git push $remote" to tell us
   where to push), but we do not know which remote branch to update.

 - The current branch does have its remote and upstream branch configured,
   but the user said "git push $there", where $there is not the remote
   named by "branch.$name.remote".  By definition, no branch at repository
   $there is set to integrate with the current branch in this case, and
   this push is not meant to update any branch at the remote repository
   $there.

The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/mingw.[ch]: Change return type of exec functions to int

The POSIX standard specifies a return type of int for all six exec
functions. In addition, all exec functions return -1 on error, and
simply do not return on success. However, the current emulation of
the exec functions on mingw are declared with a void return type.

This would cause a problem should any code attempt to call the
exec function in a non-void context. In particular, if an exec
function were used in a conditional it would fail to compile.

In order to improve the fidelity of the emulation, we change the
return type of the mingw_execv[p] functions to int and return -1
on error.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command: treat inaccessible directories as ENOENT

When execvp reports EACCES, it can be one of two things:

  1. We found a file to execute, but did not have
     permissions to do so.

  2. We did not have permissions to look in some directory
     in the $PATH.

In the former case, we want to consider this a
permissions problem and report it to the user as such (since
getting this for something like "git foo" is likely a
configuration error).

In the latter case, there is a good chance that the
inaccessible directory does not contain anything of
interest. Reporting "permission denied" is confusing to the
user (and prevents our usual "did you mean...?" lookup). It
also prevents git from trying alias lookup, since we do so
only when an external command does not exist (not when it
exists but has an error).

This patch detects EACCES from execvp, checks whether we are
in case (2), and if so converts errno to ENOENT. This
behavior matches that of "bash" (but not of simpler shells
that use execvp more directly, like "dash").

Test stolen from Junio.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/diff-no-rename-empty' into pu

Forbids rename detection logic from matching two empty files as renames
during merge-recursive to prevent mismerges.

* jk/diff-no-rename-empty:
  merge-recursive: don't detect renames of empty files
  teach diffcore-rename to optionally ignore empty content
  make is_empty_blob_sha1 available everywhere
  drop casts from users EMPTY_TREE_SHA1_BIN
Merge branch 'rs/combine-diff-zero-context-at-the-beginning' into pu

Fixes an age old corner case bug in combine diff (only triggered with -U0
and the hunk at the beginning of the file needs to be shown).

* rs/combine-diff-zero-context-at-the-beginning:
  combine-diff: fix loop index underflow
Merge branch 'jc/commit-unedited-template' into pu

When "git commit --template F" errors out because the user did not touch
the message, it claimed that it aborts due to "empty message", which was
utterly wrong.

* jc/commit-unedited-template:
  Documentation/git-commit: rephrase the "initial-ness" of templates
  git-commit.txt: clarify -t requires editing message
  commit: rephrase the error when user did not touch templated log message
  commit: do not trigger bogus "has templated message edited" check
  t7501: test the right kind of breakage
Merge branch 'jk/http-backend-keep-committer-ident-env' into pu

The smart-http backend used to always override GIT_COMMITTER_* variables
with REMOTE_USER and REMOTE_ADDR.

* jk/http-backend-keep-committer-ident-env:
  http-backend: respect existing GIT_COMMITTER_* variables
Merge branch 'jc/push-upstream-sanity' into pu

"git push $there" without refspec, when the current branch is set to push
to a remote different from $there, used to push to $there using the
upstream information to a remote unreleated to $there.

This is necessary if we were to switch the push.default to 'current'.

* jc/push-upstream-sanity:
  push: error out when the "upstream" semantics does not make sense
Merge branch 'jk/branch-quiet' into pu

Even with "-q"uiet option, "checkout" used to report setting up tracking.
Also "branch" learns "-q"uiet option to squelch informational message.

* jk/branch-quiet:
  teach "git branch" a --quiet option
  checkout: suppress tracking message with "-q"
Merge branch 'jc/run-hook-env-1' into pu

Not urgent.

Updates run_hook() API to be much less specific to "commit".  It would
only be useful if people start doing more interesting things with hooks.

* jc/run-hook-env-1:
  run_hook(): enhance the interface to pass arbitrary environment
Merge branch 'sl/autoconf' into pu

Updates our configure.ac to follow a better "autoconf" style.

* sl/autoconf:
  configure: be more idiomatic
  configure: avoid some code repetitions thanks to m4_{push,pop}def
  configure: move definitions of private m4 macros before AC_INIT invocation
Merge branch 'th/difftool-diffall' into pu

Rolls the two-directory-diff logic from diffall script (in contrib/) into
"git difftool" framework.

* th/difftool-diffall:
  difftool: print list of valid tools with '--tool-help'
  difftool: teach difftool to handle directory diffs
  difftool: eliminate setup_environment function
  difftool: stop appending '.exe' to git
  difftool: remove explicit change of PATH
  difftool: exit(0) when usage is printed
  difftool: add '--no-gui' option
  difftool: parse options using Getopt::Long
Merge branch 'jb/am-include' into pu

* jb/am-include:
  am: support --include option
Merge branch 'jc/am-report-3way' into pu

* jc/am-report-3way:
  am -3: list the paths that needed 3-way fallback
Merge branch 'jc/fmt-merge-msg-people' into pu

The "fmt-merge-msg" command learns to list the primary contributors
involved in the side topic you are merging.

Will defer til 1.7.10.

* jc/fmt-merge-msg-people:
  fmt-merge-msg: show those involved in a merged series
Merge branch 'jk/run-command-eacces' into pu

When PATH contains an unreadable directory, alias expansion code did not
kick in, and failed with an error that said "git-subcmd" was not found.

* jk/run-command-eacces:
  run-command: treat inaccessible directories as ENOENT
  compat/mingw.[ch]: Change return type of exec functions to int
Merge branch 'hv/submodule-recurse-push' into pu

* hv/submodule-recurse-push:
  push: teach --recurse-submodules the on-demand option
  Refactor submodule push check to use string list instead of integer
  Teach revision walking machinery to walk multiple times sequencially

Conflicts:
	transport.h