docs: stop using asciidoc no-inline-literal

In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.

It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:

  1. The source is much easier to read when the literal
     contains punctuation. You can use `master~1` instead
     of `master{tilde}1`.

  2. They are less error-prone. Because of point (1), we
     tend to make mistakes and forget the extra layer of
     quoting.

This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).

Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:

  - HTML rendering used the ellipsis character instead of
    literal "..." in code examples (like "git log A...B")

  - some code examples used the right-arrow character
    instead of '->' because they failed to quote

  - api-config.txt did not quote tilde, and the resulting
    HTML contained a bogus snippet like:

      <tt>_{</tt> foo <tt>}bar</tt>

    which caused some parsers to choke and omit whole
    sections of the page.

  - git-commit.txt confused ``foo`` (backticks inside a
    literal) with ``foo'' (matched double-quotes)

  - mentions of `A U Thor <author@example.com>` used to
    erroneously auto-generate a mailto footnote for
    author@example.com

  - the description of --word-diff=plain incorrectly showed
    the output as "[-removed-] and {added}", not "{+added+}".

  - using "prime" notation like:

      commit `C` and its replacement `C'`

    confused asciidoc into thinking that everything between
    the first backtick and the final apostrophe were meant
    to be inside matched quotes

  - asciidoc got confused by the escaping of some of our
    asterisks. In particular,

      `credential.\*` and `credential.<url>.\*`

    properly escaped the asterisk in the first case, but
    literally passed through the backslash in the second
    case.

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

Start preparing for 1.7.10.1

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

Merge branch 'jk/run-command-eacces' into maint

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.

By Jeff King (1) and Ramsay Jones (1)
* jk/run-command-eacces:
  run-command: treat inaccessible directories as ENOENT
  compat/mingw.[ch]: Change return type of exec functions to int

Merge branch 'jc/push-upstream-sanity' into maint

The 'push to upstream' implementation was broken in some corner
cases. "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.

* jc/push-upstream-sanity:
  push: error out when the "upstream" semantics does not make sense

Merge branch 'jc/maint-clean-nested-worktree-in-subdir' into maint

"git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the protection
applied only to such working trees that are at the top-level of the
current project by mistake.

* jc/maint-clean-nested-worktree-in-subdir:
  clean: preserve nested git worktree in subdirectories

Merge branch 'jk/diff-no-rename-empty' into maint

Rename detection logic used to match two empty files as renames during
merge-recursive, leading unnatural mismerges.

By Jeff King
* 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 maint

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) has been
fixed.

By René Scharfe
* rs/combine-diff-zero-context-at-the-beginning:
  combine-diff: fix loop index underflow

Merge branch 'jc/commit-unedited-template' into maint

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.

By Junio C Hamano (4) and Adam Monsen (1)
* 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/add-p-skip-conflicts' into maint

"git add -p" is not designed to deal with unmerged paths but did
not exclude them and tried to apply funny patches only to fail.

By Jeff King
* jk/add-p-skip-conflicts:
  add--interactive: ignore unmerged entries in patch mode

Merge branch 'jc/commit-hook-authorship' into maint

"git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do so
when the end user overrode the authorship via the "GIT_AUTHOR_NAME"
environment variable.

* jc/commit-hook-authorship:
  commit: pass author/committer info to hooks
  t7503: does pre-commit-hook learn authorship?
  ident.c: add split_ident_line() to parse formatted ident line

Merge branch 'tr/maint-word-diff-regex-sticky' into maint

The regexp configured with diff.wordregex was incorrectly reused
across files.

By Thomas Rast (2) and Johannes Sixt (1)
* tr/maint-word-diff-regex-sticky:
  diff: tweak a _copy_ of diff_options with word-diff
  diff: refactor the word-diff setup from builtin_diff_cmd
  t4034: diff.*.wordregex should not be "sticky" in --word-diff

Merge branch 'jh/notes-merge-in-git-dir-worktree' into maint

Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/.  When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.

By Johan Herland (3) and Junio C Hamano (1)
* jh/notes-merge-in-git-dir-worktree:
  notes-merge: Don't remove .git/NOTES_MERGE_WORKTREE; it may be the user's cwd
  notes-merge: use opendir/readdir instead of using read_directory()
  t3310: illustrate failure to "notes merge --commit" inside $GIT_DIR/
  remove_dir_recursively(): Add flag for skipping removal of toplevel dir

Sync with 1.7.9.7

Git 1.7.9.7

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

Sync with 1.7.8.6

Git 1.7.8.6

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

Sync with 1.7.7.7

Git 1.7.7.7

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

bundle: remove stray single-quote from error message

After running rev-list --boundary to retrieve the list of boundary
commits, "git bundle create" runs its own revision walk.  If in this
stage git encounters an unfamiliar option, it writes a message with an
unbalanced quotation mark:

error: unrecognized argument: --foo'

Drop the stray quote to match the "unrecognized argument: %s" message
used elsewhere and save translators some work.

This is mostly a futureproofing measure: for now, the "rev-list
--boundary" command catches most strange arguments on its own and the
above message is not seen unless you try something esoteric like "git
bundle create test.bundle --header HEAD".

Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.7.9' into maint

* maint-1.7.9:

Merge branch 'maint-1.7.8' into maint-1.7.9

* maint-1.7.8:
  Documentation/gitweb: trivial English fixes
  fetch/receive: remove over-pessimistic connectivity check

test-subprocess: fix segfault without arguments

Check if we even have a parameter before checking its value.  Running
this command without any arguments may not make a lot of sense, but
reacting with a segmentation fault is unduly harsh.

While we're at it, avoid casting argv by declaring it const right away.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: fix prototype of gitmodules_config

Add void to make it match its definition in submodule.c.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/maint-verify-objects-remove-pessimism' into maint-1.7.8

* jc/maint-verify-objects-remove-pessimism:
  fetch/receive: remove over-pessimistic connectivity check

Merge branch 'dw/gitweb-doc-grammo' into maint-1.7.8

* dw/gitweb-doc-grammo:
  Documentation/gitweb: trivial English fixes

Merge branch 'tr/cache-tree' into maint-1.7.8

* tr/cache-tree:
  t0090: be prepared that 'wc -l' writes leading blanks
  reset: update cache-tree data when appropriate
  commit: write cache-tree data when writing index anyway
  Refactor cache_tree_update idiom from commit
  Test the current state of the cache-tree optimization
  Add test-scrap-cache-tree

Merge branch 'cb/maint-t5541-make-server-port-portable' into maint-1.7.8

* cb/maint-t5541-make-server-port-portable:
  t5541: check error message against the real port number used
  remote-curl: Fix push status report when all branches fail

Merge branch 'cn/maint-rev-list-doc' into maint-1.7.8

* cn/maint-rev-list-doc:
  Documentation: use {asterisk} in rev-list-options.txt when needed

Merge branch 'tr/maint-bundle-boundary' into maint-1.7.8

* tr/maint-bundle-boundary:
  bundle: keep around names passed to add_pending_object()
  t5510: ensure we stay in the toplevel test dir
  t5510: refactor bundle->pack conversion

Merge branch 'tr/maint-bundle-long-subject' into maint-1.7.8

* tr/maint-bundle-long-subject:
  t5704: match tests to modern style
  strbuf: improve strbuf_get*line documentation
  bundle: use a strbuf to scan the log for boundary commits
  bundle: put strbuf_readline_fd in strbuf.c with adjustments

Merge branch 'ph/rerere-doc' into maint-1.7.8

* ph/rerere-doc:
  rerere: Document 'rerere remaining'

Git 1.7.10

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

spec: add missing build dependency

Otherwise:

/usr/bin/perl Makefile.PL PREFIX='/opt/git' INSTALL_BASE=''
Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: ...) at Makefile.PL line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.
make[1]: *** [perl.mak] Error 2
make: *** [perl/perl.mak] Error 2

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
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>

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>

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>

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>

Documentation/git-commit: rephrase the "initial-ness" of templates

The description of "commit -t <file>" said the file is used "as the
initial version" of the commit message, but in the context of an SCM,
"version" is a loaded word that can needlesslyl confuse readers.

Explain the purpose of the mechanism without using "version".

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

Git 1.7.10-rc4

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

Merge branch 'pt/gitk'

* pt/gitk:
  gitk: fix setting font display with new tabbed dialog layout.
  gitk: fix tabbed preferences construction when using tcl 8.4

Sync with 1.7.9.6

Git 1.7.9.6

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

Merge branch 'jc/maint-merge-autoedit' into maint

* jc/maint-merge-autoedit:
  merge: backport GIT_MERGE_AUTOEDIT support

gitk: fix setting font display with new tabbed dialog layout.

The changes to the dialog window tree broke the preview of the selected
font on the button. This corrects that issue.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitk: fix tabbed preferences construction when using tcl 8.4

In 8.5 the incr command creates the target variable if it does not exist
but in 8.4 using incr on a non-existing variable raises an error. Ensure
we have created our counter variable when creating the tabbed dialog for
non-themed preferences.

Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://github.com/git-l10n/git-po

Portuguese Portuguese translations from Marco Sousa via Jiang Xin

* 'master' of git://github.com/git-l10n/git-po:
  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

l10n: Add the Dutch translation team and initialize nl.po

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>

l10n: Inital Portuguese Portugal language (pt_PT)

Signed-off-by: Marco Sousa <marcomsousa@gmail.com>

git-commit.txt: clarify -t requires editing message

Make it clear that, when using commit --template, the message *must* be
changed or the commit will be aborted.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Ivan Heffner <iheffner@gmail.com>
Signed-off-by: Adam Monsen <haircut@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  string-list: document that string_list_insert() inserts unique strings

commit: rephrase the error when user did not touch templated log message

When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).

This was because the original template support was done by piggybacking on
the check to detect an empty log message.  Split the codepaths into two
independent checks to clarify the error.

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

commit: do not trigger bogus "has templated message edited" check

When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored.  However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.

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

t7501: test the right kind of breakage

These tests try to run "git commit" with various "forbidden" combinations
of options and expect the command to fail, but they do so without having
any change added to the index.  We wouldn't be able to catch breakages
that would allow these combinations by mistake with them because the
command will fail with "nothing to commit" anyway.

Make sure we have something added to the index before running the command.

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

string-list: document that string_list_insert() inserts unique strings

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: Improve zh_CN translation for Git 1.7.10-rc3

Improvements of zh_CN translations:

 - Update translation for msg "Changes not staged for commit:".
 - Remove unnecessary leading spaces for some messages.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

config: remove useless assignment

v1.7.9-8-g270a344 (config: stop using config_exclusive_filename) replaced
config_exclusive_filename with given_config_file.  In one case this
resulted in a self-assignment, which is reported by clang as a warning.
Remove the useless code.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.10-rc3

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

correct a few doubled-word nits in comments and documentation

Found by running this command:
$ git ls-files -z|xargs -0 perl -0777 -n \
 -e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt]o)\s+\1\b/gims)' \
 -e '  {' \
 -e '    $n = ($` =~ tr/\n/\n/ + 1);' \
 -e '    ($v = $&) =~ s/\n/\\n/g;' \
 -e '    print "$ARGV:$n:$v\n";' \
 -e '  }'

Why not just git grep -E ...?
That wouldn't work then the doubled words are separated by a newline.
This is derived from a Makefile syntax-check rule in gnulib's maint.mk:
  http://git.sv.gnu.org/cgit/gnulib.git/tree/top/maint.mk

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

correct spelling: an URL -> a URL

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n updates for Git 1.7.10-rc1

* 'master' of git://github.com/git-l10n/git-po:
  Add url of Swedish l10n team in TEAMS file
  l10n: Review zh_CN translation for Git 1.7.10-rc1
  Update Swedish translation (724t0f0u).
  l10n: Update zh_CN translation for Git 1.7.10-rc1
  l10n: Update git.pot (1 new message)

tests: unset COLUMNS inherited from environment

$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add url of Swedish l10n team in TEAMS file

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: Review zh_CN translation for Git 1.7.10-rc1

Overall review of the zh_CN translation:

 - Distinguish the translations of index and stage, though they are the
   same thing.

 - Many other fixes, e.g., add the lost periods at the end of translated
   sentences.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Update Swedish translation (724t0f0u).

- Update for 1.7.10-rc1.
- Add a missing -e when generaring the "Untracked files" message.
- Fixed some wordings after playing with the localized version.

Update draft release notes to 1.7.10

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

Sync with 1.7.9.5

Git 1.7.9.5

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

Merge branch 'jn/maint-fast-import-empty-ls' into maint

* jn/maint-fast-import-empty-ls:
  fast-import: don't allow 'ls' of path with empty components
  fast-import: leakfix for 'ls' of dirty trees

Merge branch 'ph/rerere-doc' into maint

* ph/rerere-doc:
  rerere: Document 'rerere remaining'

Merge branch 'ms/maint-config-error-at-eol-linecount' into maint

* ms/maint-config-error-at-eol-linecount:
  config: report errors at the EOL with correct line number

grep doc: add --break / --heading / -W to synopsis

All of the other options were included in the synopsis, so it makes
sense to include these as well.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: improve description of GIT_EDITOR and preference order

Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section,
which could be very confusing to users. Include it in "other" subsection along
with a link to git-var(1), since that is the page that fully describes all
places where editor can be set and also their preference order.

Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed
at build time. A user could be puzzled if 'nano' pops up even when none of the
mentioned environment vars or config.editor are set. Clarify this.

Ideally, the build system should be changed to reflect the chosen fallback
editor when creating the man pages. Not sure if that is even possible though.

Signed-off-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

documentation: fix alphabetic ordered list for git-rebase man page

An alphabetic ordered list (a.) is converted to numerical in
the man page (1.) so context comments naming 'a' were confusing,
fix that by not using ordered list notation for 'a' anb 'b' items.

Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

combine-diff: fix loop index underflow

If both la and context are zero at the start of the loop, la wraps around
and we end up reading from memory far away.  Skip the loop in that case
instead.

Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge gitk changes from Paul Mackerras at git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: Teach gitk to respect log.showroot
  gitk: Add menu items for comparing a commit with the marked commit
  gitk: Speed up resolution of short SHA1 ids
  gitk: Use symbolic font names "sans" and "monospace" when available
  gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields
  gitk: Make "git describe" output clickable, too
  gitk: Fix the display of files when filtered by path
  gitk: Use a tabbed dialog to edit preferences
  gitk: Use "gitk: repo-top-level-dir" as window title

gitk: Teach gitk to respect log.showroot

In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.

"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).

Teach gitk to respect log.showroot.

[paulus@samba.org: Cleaned up the Tcl a bit, use --bool on the
 git config call]

Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
Signed-off-by: Paul Mackerras <paulus@samba.org>

Git 1.7.10-rc2

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

.mailmap: unify various old mail addresses of gitster

"git shortlog -s -e" should show a single current address with this.

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

Merge branch 'am/completion-zsh-fix'

* am/completion-zsh-fix:
  contrib/completion: "local var=()" is misinterpreted as func-decl by zsh

Merge branch 'dw/gitweb-doc-grammo'

Typofix.

* dw/gitweb-doc-grammo:
  Documentation/gitweb: trivial English fixes

merge-recursive: don't detect renames of empty files

Merge-recursive detects renames so that if one side modifies
"foo" and the other side moves it to "bar", the modification
is applied to "bar". However, our rename detection is based
on content analysis, it can be wrong (i.e., two files were
not intended as a rename, but just happen to have the same
or similar content).

This is quite rare if the files actually contain content,
since two unrelated files are unlikely to have exactly the
same content.  However, empty files present a problem, in
that there is nothing to analyze. An uninteresting
placeholder file with zero bytes may or may not be related
to a placeholder file with another name.

The result is that adding content to an empty file may cause
confusion if the other side of a merge removed it; your
content may end up in another random placeholder file that
was added.

Let's err on the side of caution and not consider empty
files as renames. This will cause a modify/delete conflict
on the merge, which will let the user sort it out
themselves.

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

teach diffcore-rename to optionally ignore empty content

Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.

However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).

This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.

One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).

A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.

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

make is_empty_blob_sha1 available everywhere

The read-cache implementation defines this static function,
but it is a generally useful concept in git. Let's give
the empty blob the same treatment as the empty tree,
providing both hex and binary forms of the sha1.

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

drop casts from users EMPTY_TREE_SHA1_BIN

This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).

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

Documentation/gitweb: trivial English fixes

Change "it's" to "its" where a possessive is intended.  Also add two
missing "the" that were noticed by Ben Walton.

Signed-off-by: David Waitzman <djw@bbn.com>

gitk: Add menu items for comparing a commit with the marked commit

Sometimes one wants to see the different between two commits that are
a long distance apart in the graph display.  This is difficult to do
with the "Diff this -> selected" and "Diff selected -> this" menu
items because the need to maintain the selection means that one can't
use the find facilities or the reference list window to navigate from
one to the other.

This provides an alternative using the mark.  Having found one commit,
one marks it with the "Mark this commit" menu item, then navigates to
the other commit and uses the new "Diff this -> marked commit" and/or
"Diff marked commit -> this" menu items.

Signed-off-by: Paul Mackerras <paulus@samba.org>

contrib/completion: "local var=()" is misinterpreted as func-decl by zsh

Certain versions of zsh seems to treat

    local var=()

as a function declaration, rather than an assignment of an empty array,
although its documentation does not suggest that this should be the case.

With zsh 4.3.15 on Fedora Core 15, this causes

  __git_ps1 " (%s)"

to trigger an error message:

  local:2: command not found: svn_url_pattern

when GIT_PS1_SHOWUPSTREAM="auto".

Signed-off-by: Alex Merry <dev@randomguy3.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:

Merge branch 'maint-1.7.8' into maint

* maint-1.7.8:
  t/Makefile: Use $(sort ...) explicitly where needed
  gitweb: Fix actionless dispatch for non-existent objects
  i18n of multi-line advice messages

merge: backport GIT_MERGE_AUTOEDIT support

Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.

Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.

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

Merge branch 'ks/sort-wildcard-in-makefile' into maint-1.7.8

* ks/sort-wildcard-in-makefile:
  t/Makefile: Use $(sort ...) explicitly where needed

Merge branch 'jc/advise-i18n' into maint-1.7.8

* jc/advise-i18n:
  i18n of multi-line advice messages

Merge branch 'jn/gitweb-unspecified-action' into maint-1.7.8

* jn/gitweb-unspecified-action:
  gitweb: Fix actionless dispatch for non-existent objects

gitk: Speed up resolution of short SHA1 ids

On large repositories such as the Linux kernel, it can take quite a
noticeable time (several seconds) for gitk to resolve short SHA1 IDs
to their long form.  This speeds up the process by maintaining lists
of IDs indexed by the first 4 characters of the SHA1 ID, speeding up
the search by a factor of 65536 on large repositories.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Use symbolic font names "sans" and "monospace" when available

The following only concerns systems using X and the client-side font
rendering framework from freedesktop.org.  Windows and Mac OS X are
not affected.

Starting with version 8.5, Tk uses freetype and fontconfig by default
to render fonts on platforms that support it.  Gitk currently defaults
to the font Helvetica for the interface and Courier for diffs, and
both unfortunately look rather bad on screen in the default
configuration on many Linux distros with anti-aliasing and poor
hinting.

It is better to default to "sans" and "monospace", which are mapped by
fontconfig to some appropriate font of the sysadmin and user's
choosing (typically Bitstream Vera Sans and Mono).  The result looks
more sensible and it makes gitk feel like a well-behaved software
citizen since its fonts match other native apps.

This patch does not change the appearance of gitk for users that have
already run it, since gitk uses the remembered UI and diff font names
from ~/.gitk.

Requested-by: Michael Biebl <biebl@debian.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Mark Hills <mark@pogo.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields

This prevents a search for a number like "105" on "All Fields" from
matching against the raw author and commit timestamps.  These
timestamps were already not searchable by themselves, and the
displayed format does not match the query string anyway.

Signed-off-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Make "git describe" output clickable, too

Automake's contribution guidelines suggest using "git describe" output
in commit logs to reference previous commits.  By contrast, in
coreutils, I had acquired the habit of using a bare SHA1 prefix (8 hex
digits), since gitk creates clickable links for that, and not for "git
describe" output.

I prefer the readability of the full "git describe" output, yet want
to retain the gitk links, so this renders as clickable not just
SHA1-like strings, but also an SHA1-like string that is prefixed by
"-g".

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Fix the display of files when filtered by path

Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
under the given directory but the file list is left empty. This is because
the path_filter function fails to match the filenames which are relative
to the working tree to the filter which is filessytem relative.
This solves the problem by making both names fully qualified filesystem
paths before performing the comparison.

Tested-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Use a tabbed dialog to edit preferences

This commit converts the user preferences dialog into a tabbed property
sheet grouping general properties, colours and font selections onto
separate pages. The previous implementation was exceeding the screen
height on some systems and this avoids such problems and permits extension
using new pages in the future.

If themed Tk is unavailable or undesired a reasonable facsimile of the
tabbed notebook widget is used instead.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Use "gitk: repo-top-level-dir" as window title

Previously, when run in a subdirectory, gitk would show the name
of this subdirectory as title, which was misleading. When run with
GIT_DIR set, it would show the cwd, which is even more misleading.

In case of non-bare repos, the .git suffix in the path is skipped.

Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>