Merge branch 'maint'

Fix sizeof usage in get_permutations

Currently it gets the size of an otherwise unrelated, unused variable
instead of the expected struct size.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mh/doc-remote-helpers'

* mh/doc-remote-helpers:
  git-remote-helpers.txt: clarify options & ref list attributes
  git-remote-helpers.txt: clarify command <-> capability correspondences
  git-remote-helpers.txt: rearrange description of capabilities
  git-remote-helpers.txt: minor grammar fix
  git-remote-helpers.txt: document missing capabilities
  git-remote-helpers.txt: document invocation before input format

git.txt: add missing info about --git-dir command-line option

Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE),
the Documentation/git.txt file did not mention that the GIT_DIR
environment variable can also be set using the --git-dir command line
option.

Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailmap: default mailmap.blob in bare repositories

The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.

We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.

We do not do the same magic in the non-bare case, because:

  1. In the common case, HEAD:.mailmap will be the same as
     the .mailmap in the working tree, which is a no-op.

  2. In the uncommon case, the user has modified .mailmap
     but not yet committed it, and would expect the working
     tree version to take precedence.

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

mailmap: fix some documentation loose-ends for mailmap.blob

Anywhere we mention mailmap.file, it is probably worth
mentioning mailmap.blob, as well.

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

index-format.txt: clarify what is "invalid"

A cache-tree entry with a negative entry count is considered invalid
by the current Git; it records that we do not know the object name
of a tree that would result by writing the directory covered by the
cache-tree as a tree object.

Clarify that any entry with a negative entry count is invalid, but
the implementations must write -1 there. This way, we can later
decide to allow writers to use negative values other than -1 to
encode optional information on such invalidated entries without
harming interoperability; we do not know what will be encoded and
how, so we keep these other negative values as reserved for now.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git(1): show link to contributor summary page

We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.

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

mailmap: clean up read_mailmap error handling

The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.

This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:

  1. Return -1 on errors.

  2. Treat a missing entry (e.g., no mailmap.file given),
     ENOENT, or a non-existent blob (for mailmap.blob) as
     "no error".

  3. Complain loudly when a real error (e.g., a transient
     I/O error, no permission to open the mailmap file,
     missing or corrupted blob object, etc) occurs.

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

mailmap: support reading mailmap from blobs

In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.

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

mailmap: refactor mailmap parsing for non-file sources

The read_single_mailmap function opens a mailmap file and
parses each line. In preparation for having non-file
mailmaps, let's pull out the line-parsing logic into its own
function (read_mailmap_line), and rename the file-parsing
function to match (read_mailmap_file).

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

contrib: update stats/mailmap script

This version changes quite a few things:

  1. The original parsed the mailmap file itself, and it did
     it wrong (it did not understand entries with an extra
     email key).

     Instead, this version uses git's "%aE" and "%aN"
     formats to have git perform the mapping, meaning we do
     not have to read .mailmap at all, but still operate on
     the current state that git sees (and it also works
     properly from subdirs).

  2. The original would find multiple names for an email,
     but not the other way around.

     This version can do either or both. If we find multiple
     emails for a name, the resolution is less obvious than
     the other way around. However, it can still be a
     starting point for a human to investigate.

  3. The original would order only by count, not by recency.

     This version can do either. Combined with showing the
     counts, it can be easier to decide how to resolve.

  4. This version shows similar entries in a blank-delimited
     stanza, which makes it more clear which options you are
     picking from.

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

.mailmap: normalize emails for Linus Torvalds

Linus used a lot of different per-machine email addresses in
the early days. This means that "git shortlog -nse" does not
aggregate his counts, and he is listed well below where he
should be (8th instead of 3rd).

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

.mailmap: normalize emails for Jeff King

I never meant anything special by using my @github.com
address; it is merely a mistake that it has sometimes bled
through to patches.

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

.mailmap: fix broken entry for Martin Langhoff

Commit adc3192 (Martin Langhoff has a new e-mail address,
2010-10-05) added a mailmap entry, but forgot that both the
old and new email addresses need to appear for one to be
mapped to the other (i.e., we do not key mailmap emails by
name).

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

.mailmap: match up some obvious names/emails

This patch updates git's .mailmap in cases where multiple
names are matched to a single email. The "master" name for
each email was chosen by:

  1. If the only difference is in the presence or absence
     of accented characters, the accented form is chosen
     (under the assumption that it is the natural spelling,
     and accents are sometimes stripped in email).

  2. Otherwise, the most commonly used name is chosen.

  3. If all names are equally common, the most recently used name is
     chosen.

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

Merge branch 'so/prompt-command'

* so/prompt-command:
  git-prompt.sh: update PROMPT_COMMAND documentation

git-prompt.sh: update PROMPT_COMMAND documentation

The description of __git_ps1 function operating in two-arg mode was
not very clear.  It said "set PROMPT_COMMAND=__git_ps1" which is not
the right usage for this mode, followed by "To customize the prompt,
do this", giving a false impression that those who do not want to
customize it can get away with no-arg form, which was incorrect.

Make it clear that this mode always takes two arguments, pre and
post, with an example.

The straight-forward one should be listed as the primary usage, and
the confusing one should be an alternate for advanced users.  Swap
the order of these two.

Acked-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2

On MinGW, GCC 4.7.2 complains about

    operation on 'p->m[end]' may be undefined

Fix this by replacing the faulty lines with those of 69825ca from

    https://github.com/ned14/nedmalloc/blob/master/nedmalloc.c

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add file completion to tcsh git completion.

For bash completion, the option '-o bashdefault' is used to indicate
that when no other choices are available, file completion should be
performed.  Since this option is not available in tcsh, no file
completion is ever performed.  Therefore, commands like 'git add ',
'git send-email ', etc, require the user to manually type out
the file name.  This can be quite annoying.

To improve the user experience we try to simulate file completion
directly in this script (although not perfectly).

The known issues with the file completion simulation are:
- Possible completions are shown with their directory prefix.
- Completions containing shell variables are not handled.
- Completions with ~ as the first character are not handled.

Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: add get_submodule_config helper funtion

Several submodule configuration variables
(e.g. fetchRecurseSubmodules) are read from .gitmodules with local
overrides from the usual git config files.  This shell function mimics
that logic to help initialize configuration variables in
git-submodule.sh.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ef/mingw-rmdir'

MinGW has a workaround when rmdir unnecessarily fails to retry with
a prompt, but the logic was kicking in when the rmdir failed with
ENOTEMPTY, i.e. was expected to fail and there is no point retrying.

* ef/mingw-rmdir:
  mingw_rmdir: do not prompt for retry when non-empty

Merge branch 'ef/mingw-tty-getpass'

Update getpass() emulation for MinGW.

* ef/mingw-tty-getpass:
  mingw: get rid of getpass implementation
  mingw: reuse tty-version of git_terminal_prompt
  compat/terminal: separate input and output handles
  compat/terminal: factor out echo-disabling
  mingw: make fgetc raise SIGINT if apropriate
  mingw: correct exit-code for SIGALRM's SIG_DFL

Merge branch 'maint'

* maint:
  git-prompt: Document GIT_PS1_DESCRIBE_STYLE

git-prompt: Document GIT_PS1_DESCRIBE_STYLE

GIT_PS1_DESCRIBE_STYLE was introduced in v1.6.3.2~35.  Document it in the
header comments.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: ignore wildcarded refspecs that update local symbolic refs

In a repository cloned from somewhere else, you typically have a
symbolic ref refs/remotes/origin/HEAD pointing at the 'master'
remote-tracking ref that is next to it.  When fetching into such a
repository with "git fetch --mirror" from another repository that
was similarly cloned, the implied wildcard refspec refs/*:refs/*
will end up asking to update refs/remotes/origin/HEAD with the
object at refs/remotes/origin/HEAD at the remote side, while asking
to update refs/remotes/origin/master the same way.  Depending on the
order the two updates happen, the latter one would find that the
value of the ref before it is updated has changed from what the code
expects.

When the user asks to update the underlying ref via the symbolic ref
explicitly without using a wildcard refspec, e.g. "git fetch $there
refs/heads/master:refs/remotes/origin/HEAD", we should still let him
do so, but when expanding wildcard refs, it will result in a more
intuitive outcome if we simply ignore local symbolic refs.

As the purpose of the symbolic ref refs/remotes/origin/HEAD is to
follow the ref it points at (e.g. refs/remotes/origin/master), its
value would change when the underlying ref is updated.

Earlier commit da3efdb (receive-pack: detect aliased updates which
can occur with symrefs, 2010-04-19) fixed a similar issue for "git
push".

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

gitweb: Sort projects with undefined ages last

Sorting gitweb's project list by age ('Last Change') currently shows
projects with undefined ages at the head of the list. This gives a less
useful result when there are a number of projects that are missing or
otherwise faulty and one is trying to see what projects have been
updated recently.

Fix by sorting these projects with undefined ages at the bottom of the
list when sorting by age.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf_add_wrapped*(): Remove unused return value

Since shortlog isn't using the return value anymore (see previous
commit), the functions can be changed to void.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

shortlog: fix wrapping lines of wraplen

A recent commit [1] fixed a off-by-one wrapping error.  As a
side-effect, the conditional in add_wrapped_shortlog_msg() to decide
whether to append a newline needs to be removed.  The function
should always append a newline, which was the case before the
off-by-one fix, because strbuf_add_wrapped_text() never returns a
value of wraplen; when it returns wraplen, the string does not end
with a newline, so this caller needs to add one anyway.

[1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one
    wrapping of text

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sh-setup: work around "unset IFS" bug in some shells

With an unset IFS, field splitting is supposed to act as if IFS is
set to the usual SP HT LF, but Marc Branchaud reports that the shell
on FreeBSD 7.2 gets this wrong.

It is easy to set it to the default value manually, and it is also
safer in case somebody tries to save the old value away and restore,
e.g.

$oIFS=$IFS
IFS=something
...
IFS=$oIFS

while forgetting that the original IFS might be unset (which can be
coded but would be more involved).

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

Sync with 1.8.0.2

* maint:
  Git 1.8.0.2
  Documentation/git-stash.txt: add a missing verb
  git(1): remove a defunct link to "list of authors"

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

Git 1.8.0.2

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

format_commit_message(): simplify calls to logmsg_reencode()

All the other callers of logmsg_reencode() pass return value of
get_commit_output_encoding() or get_log_output_encoding().  Teach
the function to optionally take NULL as a synonym to "" aka "no
conversion requested" so that we can simplify the only remaining
calling site.

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

Makefile: whitespace style fixes in macro definitions

Consistently use a single space before and after the "=" (or ":=", "+=",
etc.) in assignments to make macros.  Granted, this was not a big deal,
but I did find the needless inconsistency quite distracting.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw_rmdir: do not prompt for retry when non-empty

in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.

However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.

Fix this by setting errno, and guarding the prompting-loop with an
errno-check.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git-stash.txt: add a missing verb

Signed-off-by: Sébastien Loriot <sloriot.ml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Which merge_file() function do you mean?

There are two different static functions and one global function,
all of them called "merge_file()", with different signatures and
purposes.  Rename them all to reduce confusion in "git grep" output:

 * Rename the static one in merge-index to "merge_one_path(const char
   *path)" as that function is about asking an external command to
   resolve conflicts in one path.

 * Rename the global one in merge-file.c that is only used by
   merge-tree to "merge_blobs()", as the function takes three blobs and
   returns the merged result only in-core, without doing anything to
   the filesystem.

 * Rename the one in merge-recursive to "merge_one_file()", just to be
   fair.

Also rename merge-file.[ch] to merge-blobs.[ch].

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

t9402: Use TABs for indentation

Use TAB's for indentation, and wrap overlong lines.
Put the closing ' at the beginning of the line.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: Rename check.cvsCount and check.list

Checking and comparing the number of line in check.list and check.cvsCount
had been replaced by comparing both files line by line.
Rename the filenames to make clear which is expected and which is actual:
check.list    -> list.expected
check.cvsCount-> list.actual

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: Simplify git ls-tree

Use "git ls-tree --name-only" which does not need a sed to filter out the sha

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: Add missing &&; Code style

Add missing && at 2 places
Re-formated the sub-shell parantheses (coding style)
Added missing ] in the test_expect_success header at 2 places

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: No space after IO-redirection

Redirection should not have SP before the filename
(i.e. ">out", not "> out").

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: Dont use test_must_fail cvs

Replace "test_must_fail cvs" with "! cvs"

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: improve check_end_tree() and check_end_full_tree()

check_end_tree():
- Instead of counting lines using wc in expectCount and cvsCount:
   Sort and compare the files byte by byte with test_cmp,
   which is more exact and easier to debug
- Chain all shell comands together using &&

check_end_full_tree()
- Instead of counting lines using wc in expectCount, cvsCount and gitCount:
   Sort and compare the files byte by byte with test_cmp,
   which is more exact and easier to debug
- Break the test using two conditions anded together with -a
  into to call to test_cmp
- Chain all shell comands together using &&

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9402: sed -i is not portable

On some systems sed allows the usage of e.g.
sed -i -e "s/line1/line2/" afile
to edit the file "in place".
Other systems don't allow that: one observed behaviour is that
sed -i -e "s/line1/line2/" afile
creates a backup file called afile-e, which breaks the test.
As sed -i is not part of POSIX, avoid it.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git(1): remove a defunct link to "list of authors"

The linked page has not been showing the promised "more complete
list" for more than 6 months by now, and nobody has resurrected
the list there nor elsewhere since then.

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

Git 1.8.1-rc1

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

Documentation/diff-config: work around AsciiDoc misfortune

The line that happens to begin with indent followed by "3. " was
interpreted as if it was an enumerated list; just wrap the lines
differently to work it around for now.

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

Merge branch 'maint'

* maint:
  Update draft release notes to 1.8.0.2

Update draft release notes to 1.8.0.2

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

Merge branch 'jc/doc-push-satellite' into maint

* jc/doc-push-satellite:
  Documentation/git-push.txt: clarify the "push from satellite" workflow

Merge branch 'jc/same-encoding' into maint

Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8".  The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.

* jc/same-encoding:
  reencode_string(): introduce and use same_encoding()

Merge branch 'lt/diff-stat-show-0-lines' into maint

"git diff --stat" miscounted the total number of changed lines when
binary files were involved and hidden beyond --stat-count.  It also
miscounted the total number of changed files when there were
unmerged paths.

* lt/diff-stat-show-0-lines:
  t4049: refocus tests
  diff --shortstat: do not count "unmerged" entries
  diff --stat: do not count "unmerged" entries
  diff --stat: move the "total count" logic to the last loop
  diff --stat: use "file" temporary variable to refer to data->files[i]
  diff --stat: status of unmodified pair in diff-q is not zero
  test: add failing tests for "diff --stat" to t4049
  Fix "git diff --stat" for interesting - but empty - file changes

git-remote-helpers.txt: clarify options & ref list attributes

The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.

Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-helpers.txt: clarify command <-> capability correspondences

In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the latter.

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-helpers.txt: rearrange description of capabilities

This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-helpers.txt: minor grammar fix

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-helpers.txt: document missing capabilities

Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-helpers.txt: document invocation before input format

In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...

Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.

However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.

Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
  l10n: de.po: translate 22 new messages
  l10n: de.po: translate 825 new messages
  l10n: Update Swedish translation (1979t0f0u)
  l10n: vi.po: update to git-v1.8.0.1-347-gf94c3
  l10n: Update git.pot (5 new, 1 removed messages)

Merge branch 'rr/t4041-cleanup'

* rr/t4041-cleanup:
  t4041 (diff-submodule-option): modernize style
  t4041 (diff-submodule-option): rewrite add_file() routine
  t4041 (diff-submodule-option): parse digests sensibly
  t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs

Merge branch git://github.com/ralfth/git-po-de

* 'rt/de-l10n-updates-for-1.8.1' of git://github.com/ralfth/git-po-de:
  l10n: de.po: translate 22 new messages
  l10n: de.po: translate 825 new messages

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

l10n: de.po: translate 22 new messages

Translate 22 new messages came from git.pot
updates in 9306b5b (l10n: Update git.pot (3 new,
6 removed messages)), fe52cd6 (l10n: Update git.pot
(14 new, 3 removed messages)) and f9472e3
(l10n: Update git.pot (5 new, 1 removed messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Reviewed-by: Michael J Gruber <git@drmicha.warpmail.net>

l10n: de.po: translate 825 new messages

Translate 825 new messages came from git.pot update in
cc76011 ("l10n: Update git.pot (825 new, 24 removed messages)").

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Reviewed-by: Thomas Rast <trast@student.ethz.ch>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>

git-svn: Note about tags.

Document that 'git svn' will import SVN tags as branches.

Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Expand documentation for --follow-parent

Describe what the option --follow-parent does, and what happens if it is
set or unset.

Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Recommend use of structure options.

Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.

Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Document branches with at-sign(@).

git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.

Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mm/status-push-pull-advise'

* mm/status-push-pull-advise:
  document that statusHints affects git checkout

mingw: get rid of getpass implementation

There's no remaining call-sites, and as pointed out in the
previous commit message, it's not quite ideal. So let's just
lose it.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: reuse tty-version of git_terminal_prompt

The getpass-implementation we use on Windows isn't at all ideal;
it works in raw-mode (as opposed to cooked mode), and as a result
does not deal correcly with deletion, arrow-keys etc.

Instead, use cooked mode to read a line at the time, allowing the
C run-time to process the input properly.

Since we set files to be opened in binary-mode by default on
Windows, introduce a FORCE_TEXT macro that expands to the "t"
modifier that forces the terminal to be opened in text-mode so we
do not have to deal with CRLF issues.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat/terminal: separate input and output handles

On Windows, the terminal cannot be opened in read-write mode, so
we need distinct pairs for reading and writing. Since this works
fine on other platforms as well, always open them in pairs.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat/terminal: factor out echo-disabling

By moving the echo-disabling code to a separate function, we can
implement OS-specific versions of it for non-POSIX platforms.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: make fgetc raise SIGINT if apropriate

Set a control-handler to prevent the process from terminating, and
simulate SIGINT so it can be handled by a signal-handler as usual.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: correct exit-code for SIGALRM's SIG_DFL

Make sure SIG_DFL for SIGALRM exits with 128 + SIGALRM so other
processes can diagnose why it exits.

While we're at it, make sure we only write to stderr if it's a
terminal, and  change the output to match that of Linux.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

document that statusHints affects git checkout

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-export: make sure updated refs get updated

When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.

We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.

Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.

IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.

So:

 % git branch test master
 % git fast-export $mark_flags master
 % git fast-export $mark_flags test

Would export 'test' properly.

Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-export: don't handle uninteresting refs

They have been marked as UNINTERESTING for a reason, lets respect
that.  Currently the first ref is handled properly, but not the
rest.  Assuming that all the refs point at the same commit in the
following example:

  % git fast-export master ^uninteresting ^foo ^bar
  reset refs/heads/bar
  from :0

  reset refs/heads/foo
  from :0

  reset refs/heads/uninteresting
  from :0

  % git fast-export ^uninteresting ^foo ^bar master
  reset refs/heads/master
  from :0

  reset refs/heads/bar
  from :0

  reset refs/heads/foo
  from :0

Clearly this is wrong; the negative refs should be ignored.

After this patch:

  % git fast-export ^uninteresting ^foo ^bar master
  # nothing
  % git fast-export master ^uninteresting ^foo ^bar
  # nothing

And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:

 % git fast-export ^next next
 reset refs/heads/next
 from :0

 % git fast-export ^next next^{commit}
 # nothing
 % git fast-export ^next next~0
 # nothing
 % git fast-export ^next next~1
 # nothing
 % git fast-export ^next next~2
 # nothing

The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.

However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit.  rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.8.1-rc0

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

Merge branch 'mm/status-push-pull-advise'

Finishing touch to allow the new advice message squelched
with an advice.* configuration variable.

* mm/status-push-pull-advise:
  status: respect advice.statusHints for ahead/behind advice

status: respect advice.statusHints for ahead/behind advice

If the user has unset advice.statusHints, we already
suppress the "use git reset to..." hints in each stanza. The
new "use git push to publish..." hint is the same type of
hint. Let's respect statusHints for it, rather than making
the user set yet another advice flag.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: allow already-exists advice to be disabled

Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: rename config variable for more general use

The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice.  Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: cleanup push rules comment

Rewrite to remove inter-dependencies amongst the rules.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

launch_editor: propagate signals from editor to git

We block SIGINT and SIGQUIT while the editor runs so that
git is not killed accidentally by a stray "^C" meant for the
editor or its subprocesses. This works because most editors
ignore SIGINT.

However, some editor wrappers, like emacsclient, expect to
die due to ^C. We detect the signal death in the editor and
properly exit, but not before writing a useless error
message to stderr. Instead, let's notice when the editor was
killed by a terminal signal and just raise the signal on
ourselves.  This skips the message and looks to our parent
like we received SIGINT ourselves.

The end effect is that if the user's editor ignores SIGINT,
we will, too. And if it does not, then we will behave as if
we did not ignore it. That should make all users happy.

Note that in the off chance that another part of git has
ignored SIGINT while calling launch_editor, we will still
properly detect and propagate the failed return code from
the editor (i.e., the worst case is that we generate the
useless error, not fail to notice the editor's death).

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

run-command: do not warn about child death from terminal

SIGINT and SIGQUIT are not generally interesting signals to
the user, since they are typically caused by them hitting "^C"
or otherwise telling their terminal to send the signal.

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

launch_editor: ignore terminal signals while editor has control

The user's editor likely catches SIGINT (ctrl-C).  but if
the user spawns a command from the editor and uses ctrl-C to
kill that command, the SIGINT will likely also kill git
itself (depending on the editor, this can leave the terminal
in an unusable state).

Let's ignore it while the editor is running, and do the same
for SIGQUIT, which many editors also ignore. This matches
the behavior if we were to use system(3) instead of
run-command.

Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

launch_editor: refactor to use start/finish_command

The launch_editor function uses the convenient run_command_*
interface. Let's use the more flexible start_command and
finish_command functions, which will let us manipulate the
parent state while we're waiting for the child to finish.

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

run-command: drop silent_exec_failure arg from wait_or_whine

We do not actually use this parameter; instead we complain
from the child itself (for fork/exec) or from start_command
(if we are using spawn on Windows).

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

t4041 (diff-submodule-option): modernize style

- Enclose tests in single quotes as opposed to double quotes.  This is
  the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
  test text.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4041 (diff-submodule-option): rewrite add_file() routine

Instead of "cd there and then come back", use the "cd there in a
subshell" pattern.  Also fix '&&' chaining in one place.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4041 (diff-submodule-option): parse digests sensibly

`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter.  Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: clarify rejection of update to non-commit-ish

Pushes must already (by default) update to a commit-ish due to the fast-
forward check in set_ref_status_for_push().  But rejecting for not being
a fast-forward suggests the situation can be resolved with a merge.
Flag these updates (i.e., to a blob or a tree) as not forwardable so the
user is presented with more appropriate advice.

While updating *from* a tag object is potentially destructive, updating
*to* a tag is not.  Additionally, a push to the refs/tags/ hierarchy is
already excluded from fast-forwarding, and refs/heads/ is protected from
anything but commit objects by a check in write_ref_sha1().  Thus
someone fast-forwarding to a tag is probably not doing so by accident.
Since updating to a tag is benign and unlikely to cause confusion, allow
it in case someone finds the behavior useful.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: require force for annotated tags

Do not allow fast-forwarding of references that point to a tag object.
Updating from a tag is potentially destructive since it would likely
leave the tag dangling.  Disallowing updates to a tag also makes sense
semantically and is consistent with the behavior of lightweight tags.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: require force for refs under refs/tags/

References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter.  This behavior is oriented to
branches which are expected to move with commits.  Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: flag updates that require force

Add a flag for indicating an update to a reference requires force.
Currently the `nonfastforward` flag is used for this when generating the
status message.  A separate flag insulates dependent logic from the
details of set_ref_status_for_push().

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: keep track of "update" state separately

If the reference exists on the remote and it is not being removed, then
mark as an update.  This is in preparation for handling tags (lightweight
and annotated) exceptionally.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: add advice for rejected tag reference

Advising the user to fetch and merge only makes sense if the rejected
reference is a branch.  If none of the rejections are for branches, just
tell the user the reference already exists.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: return reject reasons as a bitset

Pass all rejection reasons back from transport_push().  The logic is
simpler and more flexible with regard to providing useful feedback.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wrap_in_html(): process message in bulk rather than line-by-line

Now that we can xml-quote an arbitrary string in O(N), there is no
reason to process the message line by line.  This change saves lots of
memory allocations and copying.

The old code would have created invalid output when there was no
body, emitting a closing </pre> without a blank line nor an opening
<pre> after the header.  The new code simply returns in this
situation without doing harm (even though either would not make much
sense in the context of imap-send that is meant to send out patches).

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>