There are two very similar blocks of code that recognize options for
the "recursive" merge strategy.  Unify them.

No functional change intended.

Cc: Avery Pennarun <apenwarr@gmail.com>
Helped-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Teach "git merge-recursive" a --renormalize option to enable the
merge.renormalize configuration.  The --no-renormalize option can
be used to override it in the negative.

So in the future, you might be able to, e.g.:

	git checkout -m -Xrenormalize otherbranch

or

	git revert -Xrenormalize otherpatch

or

	git pull --rebase -Xrenormalize

The bad part: merge.renormalize is still not honored for most
commands.  And it reveals lots of places that -X has not been plumbed
in (so we get "git merge -Xrenormalize" but not much else).

NEEDSWORK: tests

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

plain rerere performs three tasks; let us consider how the new
merge.renormalize option should apply to each.

After an unsuccessful merge, rerere records conflict hunks from the
work tree under .git/rr-cache.  If the merge was performed with
merge.renormalize enabled, both sides of the conflict hunk use the
current work tree’s end-of-line and smudge rules; there is not really
much of a choice.

After a successful manual resolution, rerere records the postimage.
Here, also, the file will be in the current work tree’s canonical
format and there is not much to do about it.

When encountering that conflict again, merge looks up the preimage
and postimage using the conflict hunk as a key and runs a three-way
merge to apply that resolution to the work tree.  Since the conflict
hunk used the current work tree’s canonical format, chances are the
version in the work tree, the preimage, and the postimage will, too.
In fact using the merge.renormalize machinery is exactly the wrong
thing to do, since its result has been run through convert_to_git
and therefore is not suitable for writing to the work tree.

The only affected caller is "git merge".

NEEDSWORK: lacks test

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Guard all test code with test_expect_success to make the
script easier to follow.  While at it, pick some other nits:

 - use test_tick (more than we have to, to be realistic);

 - 'single quotes' and \escaped HERE documents where possible
   simplify review for escaping problems;

 - omit whitespace after >redirection operators for
   consistency with other tests;

 - use "update-index --refresh" instead of testing that
   "ls-files -u" output is empty, since the former produces
   nicer output on failure;

 - compare to expected nonempty "ls-files -u" output instead
   of counting lines when it is expected to be nonempty.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add a “renormalize” bit to the ll-merge options word so callers can
decide on a case-by-case basis whether the merge is likely to have
overlapped with a change in smudge/clean rules.

This reveals a few commands that have not been taking that situation
into account, though it does not fix them.

No functional change intended.

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Improved-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

ll_merge() takes its options in a flag word, which has a few
advantages:

 - options flags can be cheaply passed around in registers, while
   an option struct passed by pointer cannot;

 - callers can easily pass 0 without trouble for no options,
   while an option struct passed by value would not allow that.

The downside is that code to populate and access the flag word can be
somewhat opaque.  Mitigate that with a few macros.

Cc: Avery Pennarun <apenwarr@gmail.com>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Cc: Junio C Hamano <gitster@pobox.com>
Cc: Avery Pennarun <apenwarr@gmail.com>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add a "renormalize" option to struct merge_options so callers can
decide on a case-by-case basis whether the merge is likely to have
overlapped with a change in smudge/clean rules.  The option defaults
to the global merge_renormalize setting for now.

No change in behavior intended.

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The merge machinery decides whether to resmudge and clean relevant
entries based on the global merge_renormalize setting, which is set by
"git merge" based on its configuration (and left alone by other
commands).

A nicer interface would make that decision a parameter to merge_trees
so callers would pass in a choice made on a call-by-call basis.
Start by making blob_unchanged stop examining the merge_renormalize
global.

In other words, this change is a trivial no-op, but it brings us
closer to something good.

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

An unusual sort of person (not me) may even enjoy the conflicts
from line-ending changes.  But more importantly, it is useful to
document that behavior so we can more easily notice if it changes
in an uncontrolled way while no one is watching.

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

checkout -m and cherry-pick have not been wired up to respect
merge.renormalize, but a naïve user would not know that.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some tweaks to simplify adding and running tests.

 - Use test_tick for predictable, sort of realistic commit dates;

 - Use test_cmp as "test_cmp expected actual" --- some crazy
   content that was not expected should cause the test to fail;

 - Remove and re-add all files at the start of each test so the
   worktree is easier to think about;

 - Avoid using cat where not necessary for clarity.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Disable CRLF expansion when convert_to_working_tree() is called from
normalize_buffer().  This improves performance when merging branches
with conflicting line endings when core.eol=crlf or core.autocrlf=true
by making the normalization act as if core.eol=lf.
Signed-off-by: NEyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a file is modified due to normalization on one branch, and deleted on
another, a merge of the two branches will result in a delete/modify
conflict for that file even if it is otherwise unchanged.

Try to avoid the conflict by normalizing and comparing the "base" file
and the modified file when their sha1s differ.  If they compare equal,
the file is considered unmodified and is deleted.
Signed-off-by: NEyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, merging across changes in line ending normalization is
painful since files containing CRLF will conflict with normalized files,
even if the only difference between the two versions is the line
endings.  Additionally, any "real" merge conflicts that exist are
obscured because every line in the file has a conflict.

Assume you start out with a repo that has a lot of text files with CRLF
checked in (A):

      o---C
     /     \
    A---B---D

B: Add "* text=auto" to .gitattributes and normalize all files to
   LF-only

C: Modify some of the text files

D: Try to merge C

You will get a ridiculous number of LF/CRLF conflicts when trying to
merge C into D, since the repository contents for C are "wrong" wrt the
new .gitattributes file.

Fix ll-merge so that the "base", "theirs" and "ours" stages are passed
through convert_to_worktree() and convert_to_git() before a three-way
merge.  This ensures that all three stages are normalized in the same
way, removing from consideration differences that are only due to
normalization.

This feature is optional for now since it changes a low-level mechanism
and is not necessary for the majority of users.  The "merge.renormalize"
config variable enables it.
Signed-off-by: NEyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* cp/textconv-cat-file:
  git-cat-file.txt: Document --textconv
  t/t8007: test textconv support for cat-file
  textconv: support for cat_file
  sha1_name: add get_sha1_with_context()

* pb/maint-perl-errmsg-no-dir:
  Git.pm: better error message

* tr/send-email-8bit:
  send-email: ask about and declare 8bit mails

* js/maint-am-rebase-invalid-author:
  am: use get_author_ident_from_commit instead of mailinfo when rebasing

* ab/blame-textconv:
  t/t8006: test textconv support for blame
  textconv: support for blame
  textconv: make the API public

Conflicts:
	diff.h

* jn/show-num-walks:
  DWIM 'git show -5' to 'git show --do-walk -5'

* maint:
  msvc: Fix some compiler warnings
  Documentation: grep: fix asciidoc problem with --
  msvc: Fix some "expr evaluates to function" compiler warnings

In particular, using the normal (or production) compiler
warning level (-W3), msvc complains as follows:

.../sha1.c(244) : warning C4018: '<' : signed/unsigned mismatch
.../sha1.c(270) : warning C4244: 'function' : conversion from \
   'unsigned __int64' to 'unsigned long', possible loss of data
.../sha1.c(271) : warning C4244: 'function' : conversion from \
   'unsigned __int64' to 'unsigned long', possible loss of data

Note that gcc issues a similar complaint about line 244 when
compiling with -Wextra.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Asciidoc interprets two dashes separated by spaces as a single big
dash. So let's escape the first dash, so that "\--" will properly
appear as "--".
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In particular, the following warning is issued while compiling
notes.c:

    notes.c(927) : warning C4550: expression evaluates to a \
function which is missing an argument list

along with identical warnings on lines 928, 1016 and 1017.

In order to suppress the warning, we change the definition of
combine_notes_fn, so that the symbol type is an (explicit)
"pointer to function ...".  As a result, several other
declarations need some minor fix-up to take account of the
new typedef.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jk/url-decode:
  url.c: "<scheme>://" part at the beginning should not be URL decoded

When using the protocol git+ssh:// for example we do not want to
decode the '+' as a space. The url decoding must take place only
for the server name and parameters.

This fixes a regression introduced in 9d2e9420.
Initial-fix-by: NPascal Obry <pascal.obry@gmail.com>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/maint-simpler-common-prefix:
  common_prefix: simplify and fix scanning for prefixes

* sb/format-patch-signature:
  completion: Add --signature and format.signature
  format-patch: Add a signature option (--signature)

* mg/pretty-magic-space:
  pretty: Introduce ' ' modifier to add space if non-empty

Conflicts:
	pretty.c

* jn/gitweb-return-or-exit-cleanup:
  gitweb: Return or exit after done serving request

Conflicts:
	gitweb/gitweb.perl

* bd/maint-unpack-trees-parawalk-fix:
  unpack-trees: Make index lookahead less pessimal

* cc/cherry-pick-series:
  Documentation/revert: describe passing more than one commit
  Documentation/cherry-pick: describe passing more than one commit
  revert: add tests to check cherry-picking many commits
  revert: allow cherry-picking more than one commit
  revert: change help_msg() to take no argument
  revert: refactor code into a do_pick_commit() function
  revert: use run_command_v_opt() instead of execv_git_cmd()
  revert: cleanup code for -x option

* jc/rev-list-ancestry-path:
  revision: Turn off history simplification in --ancestry-path mode
  revision: Fix typo in --ancestry-path error message
  Documentation/rev-list-options.txt: Explain --ancestry-path
  Documentation/rev-list-options.txt: Fix missing line in example history graph
  revision: --ancestry-path

* lt/extended-sha1-match-commit-with-regexp:
  Make :/ accept a regex rather than a fixed pattern

* maint:
  Update draft release notes to 1.7.1.1
  tests: remove unnecessary '^' from 'expr' regular expression

Conflicts:
	diff.c