push: start warning upcoming default change for push.default

In preparation for flipping the default to the "upstream" mode from
the "matching" mode that is the historical default, start warning
users when they rely on unconfigured "git push" to default to the
"matching" mode.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: Provide situational hints for non-fast-forward errors

Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:

1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.

2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.

3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.

Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.

Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clean up struct ref's nonfastforward field

Each ref structure contains a "nonfastforward" field which
is set during push to show whether the ref rewound history.
Originally this was a single bit, but it was changed in
f25950f (push: Provide situational hints for non-fast-forward
errors) to an enum differentiating a non-ff of the current
branch versus another branch.

However, we never actually set the member according to the
enum values, nor did we ever read it expecting anything but
a boolean value. But we did use the side effect of declaring
the enum constants to store those values in a totally
different integer variable. The code as-is isn't buggy, but
the enum declaration inside "struct ref" is somewhat
misleading.

Let's convert nonfastforward back into a single bit, and
then define the NON_FF_* constants closer to where they
would be used (they are returned via the "int *nonfastforward"
parameter to transport_push, so we can define them there).

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

* master:
  Git 1.7.10-rc3
  correct a few doubled-word nits in comments and documentation
  correct spelling: an URL -> a URL
Merge branch 'ct/advise-push-default' into next

Breaks down the cases in which "git push" fails due to non-ff into three
categories, and gives separate advise messages.  This should be a good
change regardless of mm/push-default-switch-warning topic.

* ct/advise-push-default:
  clean up struct ref's nonfastforward field
  push: Provide situational hints for non-fast-forward errors
Merge branch 'mm/push-default-switch-warning' into next

This resurrects an ancient patch I wrote during a discussion we had in the
1.6.3-1.6.4 era.  This should probably come after ct/advise-push-default
topic and at that point the advise messages need to be rephrased, taking
the future default change into account.

* mm/push-default-switch-warning:
  push: start warning upcoming default change for push.default

Conflicts:
	builtin/push.c
Merge branch 'master' into next

* master:
  config: remove useless assignment
Merge branch 'master' into next

* master:
  string-list: document that string_list_insert() inserts unique strings
Merge branch 'master' into next

* master:
  Git 1.7.9.6
  l10n: Add the Dutch translation team and initialize nl.po
  l10n: Inital Portuguese Portugal language (pt_PT)
  l10n: Improve zh_CN translation for Git 1.7.10-rc3
  merge: backport GIT_MERGE_AUTOEDIT support
Sync with 1.7.10-rc4

* tag 'v1.7.10-rc4':
  Git 1.7.10-rc4
  gitk: fix setting font display with new tabbed dialog layout.
  gitk: fix tabbed preferences construction when using tcl 8.4
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").
http-backend: respect existing GIT_COMMITTER_* variables

The http-backend program sets default GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL variables based on the REMOTE_USER and
REMOTE_ADDR variables provided by the webserver. However, it
unconditionally overwrites any existing GIT_COMMITTER
variables, which may have been customized by site-specific
code in the webserver (or in a script wrapping http-backend).

Let's leave those variables intact if they already exist,
assuming that any such configuration was intentional. There
is a slight chance of a regression if somebody has set
GIT_COMMITTER_* for the entire webserver, not intending it
to leak through http-backend. We could protect against this
by passing the information in alternate variables.  However,
it seems unlikely that anyone will care about that
regression, and there is value in the simplicity of using
the common variable names that are used elsewhere in git.

While we're tweaking the environment-handling in
http-backend, let's switch it to use argv_array to handle
the list of variables. That makes the memory management much
simpler.
checkout: suppress tracking message with "-q"

Like the "switched to..." message (which is already
suppressed by "-q"), this message is purely informational.
Let's silence it if the user asked us to be quiet.

This patch is slightly more than a one-liner, because we
have to teach create_branch to propagate the flag all the
way down to install_branch_config.
teach "git branch" a --quiet option

There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages.  This
patch provides a "-q" option to do so.
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).
Merge branch 'jk/add-unmerged' into HEAD

* jk/add-unmerged:
  add--interactive: ignore unmerged entries in patch mode
Merge branch 'jk/blame-tree' into HEAD

* jk/blame-tree:
  blame-tree wip
Merge branch 'jk/builtin-attr' into HEAD

* jk/builtin-attr:
  attr: drop C/C++ default extension mapping
  attr: map builtin userdiff drivers to well-known extensions
Merge branch 'jk/bundle-fetch' into HEAD

* jk/bundle-fetch:
  clone: give advice on how to resume a failed clone
  remote-curl: resume interrupted bundle transfers
  remote-curl: show progress for bundle downloads
  progress: allow pure-throughput progress meters
  remote-curl: try base $URL after $URL/info/refs
  remote-curl: auto-detect bundles when fetching refs
  remote-curl: free "discovery" object
  bundle: add is_bundle_buf helper
  transport: factor out bundle to ref list conversion
  remote-curl: use http callback for requesting refs
  http: add a public function for arbitrary-callback request
  http: refactor http_request function
  http: turn off curl signals
  t/lib-httpd: check for NO_CURL

Conflicts:
	http.c
Merge branch 'jk/byte-diff' into HEAD

* jk/byte-diff:
  diff: implement --bytediff mode for numstat