t7800: move '--symlinks' specific test to the end

This will group the tests more logically when we introduce a helper to
run most --dir-diff tests with both --symlinks and --no-symlinks.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: don't overwrite modified files

After running the user's diff tool, git-difftool will copy any files
that differ between the working tree and the temporary tree.  This is
useful when the user edits the file in their diff tool but is wrong if
they edit the working tree file while examining the diff.

Instead of copying unconditionally when the files differ, create and
index from the working tree files and only copy the temporary file back
if it was modified and the working tree file was not.  If both files
have been modified, print a warning and exit with an error.

Note that we cannot use an existing index in git-difftool since those
contain the modified files that need to be checked out but here we are
looking at those files which are copied from the working tree and not
checked out.  These are precisely the files which are not in the
existing indices.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7800: don't hide grep output

Remove the stdin_contains and stdin_doesnt_contain helper functions
which add nothing but hide the output of grep, hurting debugging.

Suggested-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7800: fix tests when difftool uses --no-symlinks

When 'git difftool --dir-diff' is using --no-symlinks (either explicitly
or implicitly because it's running on Windows), any working tree files
that have been copied to the temporary directory are copied back after
the difftool completes.

Because an earlier test uses "git add .", the "output" file used by
tests is tracked by Git and the following sequence occurs during some
tests:

1) the shell opens "output" to redirect the difftool output
2) difftool copies the empty "output" to the temporary directory
3) difftool runs "ls" which writes to "output"
4) difftool copies the empty "output" file back over the output of the
   command
5) the output file doesn't contain the expected output, causing the
   test to fail

Instead of adding all changes, explicitly add only the files that the
test is using, allowing later tests to write their result files into the
working tree.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7800: run --dir-diff tests with and without symlinks

Currently the difftool --dir-diff tests may or may not use symlinks
depending on the operating system on which they are run.  In one case
this has caused a test failure to be noticed only on Windows when the
test also fails on Linux when difftool is invoked with --no-symlinks.

Rewrite these tests so that they do not depend on the environment but
run explicitly with both --symlinks and --no-symlinks, protecting the
--symlinks version with a SYMLINKS prerequisite.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1300: document some aesthetic failures of the config editor

The config-editing code used by "git config var value" is
built around the regular config callback parser, whose only
triggerable item is an actual key. As a result, it does not
know anything about section headers, which can result in
unnecessarily ugly output:

  1. When we delete the last key in a section, we should be
     able to delete the section header.

  2. When we add a key into a section, we should be able to
     reuse the same section header, even if that section did
     not have any keys in it already.

Unfortunately, fixing these is not trivial with the current
code. It would involve the config parser recording and
passing back information on each item it finds, including
headers, keys, and even comments (or even better, generating
an actual in-memory parse-tree).

Since these behaviors do not cause any functional problems
(i.e., the resulting config parses as expected, it is just
uglier than one would like), fixing them can wait until
somebody feels like substantially refactoring the parsing
code. In the meantime, let's document them as known issues
with some tests.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/apply-ws-fix-tab-in-indent' into jch

"git apply --whitespace=fix" was not prepared to see a line getting
longer after fixing whitespaces (e.g. tab-in-indent aka Python).

* jc/apply-ws-fix-tab-in-indent:
  test: resurrect q_to_tab
  apply --whitespace=fix: avoid running over the postimage buffer
Merge branch 'sw/safe-create-leading-dir-race' into jch

* sw/safe-create-leading-dir-race:
  safe_create_leading_directories: fix race that could give a false negative
### match next
commit.c: also look at the first GPG status line

GPG signature verification failed to check the status line when
the expected output appeared at the very first line.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge/pull: verify GPG signatures of commits being merged

When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge/pull Check for untrusted good GPG signatures

When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty printing: extend %G? to include 'N' and 'U'

Expand %G? in pretty format strings to 'N' in case of no GPG signature
and 'U' in case of a good but untrusted GPG signature in addition to
the previous 'G'ood and 'B'ad. This eases writing anyting parsing
git-log output.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tb/cygwin-shared-repository' into jch

Cygwin port has a faster-but-lying lstat(2) emulation whose
incorrectness does not matter in practice except for a few
codepaths, and setting permission bits to directories is a codepath
that needs to use a more correct one.

Comments?

* tb/cygwin-shared-repository:
  Make core.sharedRepository work under cygwin 1.7
Merge branch 'jk/difftool-no-overwrite-on-copyback' into jch

* jk/difftool-no-overwrite-on-copyback:
  t7800: run --dir-diff tests with and without symlinks
  t7800: fix tests when difftool uses --no-symlinks
  t7800: don't hide grep output
  difftool: don't overwrite modified files
  t7800: move '--symlinks' specific test to the end
Merge branch 'jc/merge-tag-object' into jch

"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2" as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload.

This makes the code notice the type of the tag object, in addition
to the dwim_ref() based classification the current code uses
(i.e. the name appears in refs/tags/) to decide when to special
case merging of tags.

We may actually want to call the current behaviour a feature,
though.  After all, the user went to great length to feed something
different from the normal "v1.8.2" to the command.

* jc/merge-tag-object:
  merge: a random object may not necssarily be a commit
Merge branch 'jc/push-2.0-default-to-simple' into jch

* jc/push-2.0-default-to-simple:
  advice: Remove unused advice_push_non_ff_default
  t5570: do not assume the "matching" push is the default
  t5551: do not assume the "matching" push is the default
  t5550: do not assume the "matching" push is the default
  doc: push.default is no longer "matching"
  push: switch default from "matching" to "simple"
  t9401: do not assume the "matching" push is the default
  t9400: do not assume the "matching" push is the default
  t7406: do not assume the "matching" push is the default
  t5531: do not assume the "matching" push is the default
  t5519: do not assume the "matching" push is the default
  t5517: do not assume the "matching" push is the default
  t5516: do not assume the "matching" push is the default
  t5505: do not assume the "matching" push is the default
  t5404: do not assume the "matching" push is the default

# Conflicts:
# 	Documentation/config.txt
# 	Documentation/git-push.txt
# 	builtin/push.c
# 	t/t5516-fetch-push.sh
Merge branch 'jc/add-2.0-delete-default' (early part) into jch

* 'jc/add-2.0-delete-default' (early part):
  git add: start preparing for "git add <pathspec>..." to default to "-A"
  builtin/add.c: simplify boolean variables
Merge branch 'jc/add-2.0-delete-default' into jch

"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users.  They
can of course use "git add -A dir/", but why should they?

There seemed to be some interest in this topic, so resurrected and
rebased on top of recent documentation updates to propose a
possible transition plan.

* jc/add-2.0-delete-default:
  git add <pathspec>... defaults to "-A"
Merge branch 'jn/add-2.0-u-A-sans-pathspec' into jch

Replaces jc/add-2.0-u-A-sans-pathspec topic by not warning against
"add -u/-A" that is ran without pathspec when there is no change
outside the current directory.

$gmane/219342

* jn/add-2.0-u-A-sans-pathspec:
  git add: -u/-A now affects the entire working tree
  add -A: only show pathless 'add -A' warning when changes exist outside cwd
  add -u: only show pathless 'add -u' warning when changes exist outside cwd
  add: make warn_pathless_add() a no-op after first call
  add: make pathless 'add [-u|-A]' warning a file-global function