Merge branch 'mh/fetch-into-shallow' into maint

* mh/fetch-into-shallow:
  t5500: add test for fetching with an unknown 'shallow'
  upload-pack: ignore 'shallow' lines with unknown obj-ids

Merge branch 'jh/checkout-auto-tracking' into maint

* jh/checkout-auto-tracking:
  glossary: Update and rephrase the definition of a remote-tracking branch
  branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
  t9114.2: Don't use --track option against "svn-remote"-tracking branches
  t7201.24: Add refspec to keep --track working
  t3200.39: tracking setup should fail if there is no matching refspec.
  checkout: Use remote refspecs when DWIMming tracking branches
  t2024: Show failure to use refspec when DWIMming remote branch names
  t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'

Update draft release notes to 1.8.4

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/add-i-custom-diff-algo'

* jk/add-i-custom-diff-algo:
  add -i: add extra options at the right place in "diff" command line
  add--interactive: respect diff.algorithm

Merge branch 'rr/cherry-pick-fast-forward-reflog-message'

The reflog message created when "git cherry-pick" fast-forwarded
did not say anything but "cherry-pick", but it now says
"cherry-pick: fast-forward".

* rr/cherry-pick-fast-forward-reflog-message:
  sequencer: write useful reflog message for fast-forward

Merge branch 'mt/send-email-cc-match-fix'

Logic used by git-send-email to suppress cc mishandled names that
need RFC2047 quoting.

* mt/send-email-cc-match-fix:
  send-email: sanitize author when writing From line
  send-email: add test for duplicate utf8 name

Merge branch 'jk/pull-into-dirty-unborn'

"git pull" into nothing trashed "local changes" that were in the
index, and this avoids it.

* jk/pull-into-dirty-unborn:
  pull: merge into unborn by fast-forwarding from empty tree
  pull: update unborn branch tip after index

Merge branch 'bc/http-keep-memory-given-to-curl'

Older cURL wanted piece of memory we call it with to be stable, but
we updated the auth material after handing it to a call.

* bc/http-keep-memory-given-to-curl:
  http.c: don't rewrite the user:passwd string multiple times

Merge branch 'bc/checkout-tracking-name-plug-leak'

Plug a small leak in checkout.

* bc/checkout-tracking-name-plug-leak:
  t/t9802: explicitly name the upstream branch to use as a base
  builtin/checkout.c: don't leak memory in check_tracking_name

Merge branch 'rr/rebase-stash-store'

Finishing touches for the "git rebase --autostash" feature
introduced earlier.

* rr/rebase-stash-store:
  rebase: use 'git stash store' to simplify logic
  stash: introduce 'git stash store'
  stash: simplify option parser for create
  stash doc: document short form -p in synopsis
  stash doc: add a warning about using create

rebase -i: handle fixup! fixup! in --autosquash

In rebase -i --autosquash, ignore all "fixup! " or "squash! " after the
first.  This supports the case when a git commit --fixup/--squash referred
to an earlier fixup/squash instead of the original commit (whether
intentionally, as when the user expressly meant to note that the commit
fixes an earlier fixup; or inadvertently, as when the user meant to refer to
the original commit with :/msg; or out of laziness, as when the user could
remember how to refer to the fixup but not the original).

In the todo list, the full commit message is preserved, in case it provides
useful cues to the user.  A test helper set_cat_todo_editor is introduced to
check this.

Helped-by: Thomas Rast <redacted>
Helped-by: Junio C Hamano <redacted>
Signed-off-by: Andrew Pimlott <redacted>
Signed-off-by: Junio C Hamano <redacted>

am: replace uses of --resolved with --continue

git am was previously modified to provide --continue for consistency
with rebase, merge etc, and the documentation changed to showing
--continue as the primary form.

Complete the work by replacing remaining uses of --resolved by
--continue, most notably in suggested command reminders.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

Update draft release notes to 1.8.4

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'tr/maint-apply-non-git-patch-parsefix'

Fix for the codepath to parse patches that add new files, generated
by programs other than Git.  THis is an old breakage in v1.7.11 and
will need to be merged down to the maintanance tracks.

* tr/maint-apply-non-git-patch-parsefix:
  apply: carefully strdup a possibly-NULL name

Merge branch 'ys/cygstart'

On Cygwin, recognize "cygstart" as a possible way to start a web
browser (used in "help -w" and "instaweb" among others).

* ys/cygstart:
  web--browse: support /usr/bin/cygstart on Cygwin

Merge branch 'wk/doc-git-has-grown'

* wk/doc-git-has-grown:
  user-manual: Update download size for Git and the kernel

Merge branch 'vl/typofix'

* vl/typofix:
  random typofixes (committed missing a 't', successful missing an 's')

Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'

* ph/builtin-srcs-are-in-subdir-these-days:
  fix "builtin-*" references to be "builtin/*"

Merge branch 'mm/merge-in-dirty-worktree-doc'

* mm/merge-in-dirty-worktree-doc:
  Documentation/git-merge.txt: weaken warning about uncommited changes

Merge branch 'kb/diff-blob-blob-doc'

* kb/diff-blob-blob-doc:
  Documentation: Move "git diff <blob> <blob>"

Merge branch 'mm/push-force-is-dangerous'

* mm/push-force-is-dangerous:
  Documentation/git-push.txt: explain better cases where --force is dangerous

Merge branch 'fg/submodule-non-ascii-path'

Many "git submodule" operations do not work on a submodule at a
path whose name is not in ASCII.

* fg/submodule-non-ascii-path:
  t7400: test of UTF-8 submodule names pass under Mac OS
  handle multibyte characters in name

documentation: add git:// transport security notice

The fact that the git:// transport does no authentication is easily
overlooked.  For example, DNS poisoning may result in fetching from
somewhere that was not intended.

Add a brief security notice to the "GIT URLS" section
of the documentation stating that the git transport should be used
with caution on unsecured networks.

Signed-off-by: Fraser Tweedale <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-prompt.sh: add missing information in comments

Mention that the command below is needed for prompt
in ZSH with PS1:
  setopt PROMPT_SUBST

Rephrase some parts that mention only the "current branch name"
being displayed in the prompt. Replace it by stating that
the "repository status" is displayed.

Make it clear that colored prompt is only available
in PROMPT_COMMAND/precmd mode.

With-suggestions-by: SZEDER Gábor <redacted>
Signed-off-by: Eduardo R. D'Avila <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-prompt.sh: do not print duplicate clean color code

Do not print a duplicate clean color code when there
is no other indicators other than the current branch
in colored prompt.

Acked-by: SZEDER Gábor <redacted>
Signed-off-by: Eduardo R. D'Avila <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9903: remove redundant tests

After refactoring __git_ps1_colorize_gitstring, codepaths for bash and zsh
became mostly common and tests for bash and zsh became redundant.

Remove tests for zsh. Keep one minimal test that stress the difference
in codepaths for bash and zsh.

Suggested-by: SZEDER Gábor <redacted>
Signed-off-by: Eduardo R. D'Avila <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-prompt.sh: refactor colored prompt code

__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.

Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring() and __git_ps1().

Leave in __git_ps1_colorize_gitstring() only logic
to set color codes.

Signed-off-by: Eduardo R. D'Avila <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9903: add tests for git-prompt pcmode

git-prompt.sh lacks tests for PROMPT_COMMAND mode.

Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh

Having these tests enables an upcoming refactor in
a safe way.

Signed-off-by: Eduardo R. D'Avila <redacted>
Signed-off-by: Junio C Hamano <redacted>

pretty: --format output should honor logOutputEncoding

One can set an alias
$ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
and
$ git reset --hard

This patch makes pretty --format honor logOutputEncoding when it formats
log message.

Signed-off-by: Alexey Shumkin <redacted>
Signed-off-by: Junio C Hamano <redacted>

pretty: Add failing tests: --format output should honor logOutputEncoding

One can set an alias
$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
and
$ git reset --hard

This patch adds failing tests for the next patch that fixes them.

Signed-off-by: Alexey Shumkin <redacted>
Signed-off-by: Junio C Hamano <redacted>

t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7102 (reset): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin <redacted>
Signed-off-by: Junio C Hamano <redacted>

test: run testcases with POSIX absolute paths on Windows

Some test cases are skipped on Windows by marking with POSIX prereq.
This is because arguments look like absolute paths (such as /a/b)
for regular Windows programs (*.exe executables, no bash scripts)
are changed to Windows paths (like C:/msysgit/a/b).

There is no cygpath nor equivalent on msysGit, but it is easy to
write one. New subcommand "mingw_path" is added in test-path-utils,
so that we can get the expected absolute paths on Windows. E.g.

    COMMAND LINE                        Linux output  Windows output
    ==================================  ============  ===============
    test-path-utils mingw_path /        /             C:/msysgit
    test-path-utils mingw_path /a/b/    /a/b/         C:/msysgit/a/b/

With this utility, most skipped test cases in t0060 can be turned on
to be tested correctly on Windows.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: use a git-add-interactive compatible UI

Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.

Please NOTE:

 * Method `list_and_choose` return an array of integers, and
 * it is up to you to free the allocated memory of the array.
 * The array ends with EOF.
 * If user pressed CTRL-D (i.e. EOF), no selection returned.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

test: add t7301 for git-clean--interactive

Add test cases for git-clean--interactive.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add colors to interactive git-clean

Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive.<slot>" for command `git-add--interactive`.

Signed-off-by: Jiang Xin <redacted>
Comments-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add documentation for interactive git-clean

Add new section "Interactive mode" for documentation of interactive
git-clean.

Signed-off-by: Jiang Xin <redacted>
Helped-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: show items of del_list in columns

When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.

Signed-off-by: Jiang Xin <redacted>
Comments-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add ask each interactive action

Add a new action for interactive git-clean: ask each. It's just like
the "rm -i" command, that the user must confirm one by one for each
file or directory to be cleaned.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add support for -i/--interactive

Show what would be done and the user must confirm before actually
cleaning.

    Would remove ...
    Would remove ...
    Would remove ...

    Remove [y/n]?

Press "y" to start cleaning, and press "n" if you want to abort.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add select by numbers interactive action

Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.

User can input:

 *  1,5-7 : select 1,5,6,7 items to be deleted
 *  *     : select all items to be deleted
 *  -*    : unselect all, nothing will be deleted
 *        : (empty) finish selecting, and return back to main menu

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: refactor git-clean into two phases

Before introducing interactive git-clean, refactor git-clean operations
into two phases:

 * hold cleaning items in del_list,
 * and remove them in a separate loop at the end.

We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and must confirm
before do real cleaning.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-clean: add filter by pattern interactive action

Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, presses ENTER and backs to the confirmation dialog.

Signed-off-by: Jiang Xin <redacted>
Suggested-by: Junio C Hamano <redacted>
Signed-off-by: Junio C Hamano <redacted>

write_name{_quoted_relative,}(): remove redundant parameters

After substitute path_relative() in quote.c with relative_path()
from path.c, parameters (such as len and prefix_len) are redundant
in function write_name() and write_name_quoted_relative().  The
callers have already been audited that the strings they pass are
properly NUL terminated and the length they give are the length of
the string (or -1 that asks the length to be counted by the callee).

Remove these now-redundant parameters.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

quote_path_relative(): remove redundant parameter

quote_path_relative() used to take a counted string as its parameter
(the string to be quoted).  With an earlier change, it now uses
relative_path() that does not take a counted string, and we have
been passing only the pointer to the string since then.

Remove the length parameter from quote_path_relative() to show that
this parameter was redundant.  All the changed lines show that the
caller passed either -1 (to ask the function run strlen() on the
string), or the length of the string, so the earlier conversion was
safe.

All the callers of quote_path_relative() that used to take counted string
have been audited to make sure that they are passing length of the actual
string (or -1 to ask the callee run strlen())

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

quote.c: substitute path_relative with relative_path

Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.

Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b/      c/                       c/
    /a/b/c    /a/b/      c                        c
    /a/       /a/b/      ../                      ../
    /         /a/b/      ../../                   ../../
    /a/c      /a/b/      ../c                     ../c
    /x/y      /a/b/      ../../x/y                ../../x/y
    a/b/c/    a/b/       c/                       c/
    a/        a/b/       ../                      ../
    x/y       a/b/       ../../x/y                ../../x/y
    /a/b      (empty)    /a/b                     /a/b
    /a/b      (null)     /a/b                     /a/b
    a/b       (empty)    a/b                      a/b
    a/b       (null)     a/b                      a/b

But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/     /a/b/      (empty)                  ./
    a/b/      a/b/       (empty)                  ./
    (empty)   (null)     (empty)                  ./
    (empty)   (empty)    (empty)                  ./

But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:

 * In function quote_path_relative, if the output of path_relative is
   empty, append "./" to it, like:

       if (!out->len)
           strbuf_addstr(out, "./");

 * Another caller is write_name_quoted_relative, which is only used
   by builtin/ls-files.c. git-ls-files only show files, so path of
   files will never be identical with the prefix of a directory.

The following differences show that path_relative does not handle
extra slashes properly:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a//b//c/ //a/b//    ../../../../a//b//c/     c/
    a/b//c    a//b       ../b//c                  c

And if prefix has no trailing slash, path_relative does not work
properly either.  But since prefix always has a trailing slash, it's
not a problem.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b       b/c/                     c/
    /a/b      /a/b       b                        ./
    /a/b/     /a/b       b/                       ./
    /a        /a/b/      ../../a                  ../
    a/b/c/    a/b        b/c/                     c/
    a/b/      a/b        b/                       ./
    a         a/b        ../a                     ../
    x/y       a/b/       ../x/y                   ../../x/y
    a/c       a/b        c                        ../c
    /a/       /a/b       (empty)                  ../
    (empty)   /a/b       ../../                   ./

One tricky part in this conversion is write_name() function in
ls-files.c.  It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted.  Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:

 - For <name, len>, all three callers of write_name() passes a
   NUL-terminated string and its true length, so this patch makes
   "len" unused.

 - For <prefix, prefix_len>, prefix could be a string that is longer
   than empty while prefix_len could be 0 when "--full-name" option
   is used.  This is fixed by checking prefix_len in write_name()
   and calling write_name_quoted_relative() with NULL when
   prefix_len is set to 0.  Again, this makes "prefix_len" given to
   write_name_quoted_relative() unused, without introducing a bug.

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

path.c: refactor relative_path(), not only strip prefix

Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs).

In most cases, we need a real relative path, such as: ../foo,
../../bar.  That's why there is another reimplementation
(path_relative()) in quote.c.

Borrow some codes from path_relative() in quote.c to refactor
relative_path() in path.c, so that it could return real relative
path, and user can reuse this function without reimplementing
his/her own.  The function path_relative() in quote.c will be
substituted, and I would use the new relative_path() function when
implementing the interactive git-clean later.

Different results for relative_path() before and after this refactor:

    abs path  base path  relative (original)  relative (refactor)
    ========  =========  ===================  ===================
    /a/b      /a/b       .                    ./
    /a/b/     /a/b       .                    ./
    /a        /a/b/      /a                   ../
    /         /a/b/      /                    ../../
    /a/c      /a/b/      /a/c                 ../c
    /x/y      /a/b/      /x/y                 ../../x/y

    a/b/      a/b/       .                    ./
    a/b/      a/b        .                    ./
    a         a/b        a                    ../
    x/y       a/b/       x/y                  ../../x/y
    a/c       a/b        a/c                  ../c

    (empty)   (null)     (empty)              ./
    (empty)   (empty)    (empty)              ./
    (empty)   /a/b       (empty)              ./
    (null)    (null)     (null)               ./
    (null)    (empty)    (null)               ./
    (null)    /a/b       (segfault)           ./

You may notice that return value "." has been changed to "./".
It is because:

 * Function quote_path_relative() in quote.c will show the relative
   path as "./" if abs(in) and base(prefix) are the same.

 * Function relative_path() is called only once (in setup.c), and
   it will be OK for the return value as "./" instead of ".".

Signed-off-by: Jiang Xin <redacted>
Signed-off-by: Junio C Hamano <redacted>

test: add test cases for relative_path

Add subcommand "relative_path" in test-path-utils, and add test cases
in t0060.

Johannes tested an earlier version of this patch on Windows, and
found that some relative_path tests should be skipped on
Windows. This is because the bash on Windows rewrites arguments of
regular Windows programs, such as git and the test helpers, if the
arguments look like absolute POSIX paths. As a consequence, the
actual tests performed are not what the tests scripts expect.

The tests that need *not* be skipped are those where the two paths passed
to 'test-path-utils relative_path' have the same prefix and the result is
expected to be a relative path. This is because the rewriting changes
"/a/b" to "D:/Src/MSysGit/a/b", and when both inputs are extended the same
way, this just cancels out in the relative path computation.

Signed-off-by: Jiang Xin <redacted>
Helped-by: Johannes Sixt <redacted>
Signed-off-by: Junio C Hamano <redacted>

column doc: rewrite documentation for column.ui

The configuration option column.ui is very poorly documented, and it is
unclear what the defaults are, and what option can be combined with
what.  Rewrite it by splitting up the options into three sections
clearly showing how COL_ENABLED, COL_LAYOUT_MASK, and COL_DENSE work.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

.mailmap: Map "H.Merijn Brand" to "H. Merijn Brand"

This patch was created by searching for duplicates of email addresses
in the shortlog by
    git shortlog -sne |awk '{ print $NF }' |sort |uniq -d

This will yield all email addresses, which are found multiple times within
the shortlog. We can assume that commiters having the same email address
are indeed the same person.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: demote core.safecrlf=true to core.safecrlf=warn

Otherwise the user will not be able to start to guess where in the
contents in the working tree the offending unsafe CR lies.

Signed-off-by: Junio C Hamano <redacted>

Update draft release notes to 1.8.4

For now, comment out the description on two "git status" UI
configuration, until the reverted topic can be resurrected.

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'rr/am-quit-empty-then-abort-fix'

Recent "rebase --autostash" update made it impossible to recover
with "git am --abort" from a repository where "git am" without mbox
was run by mistake and then was killed with "^C".

* rr/am-quit-empty-then-abort-fix:
  t/am: use test_path_is_missing() where appropriate
  am: handle stray $dotest directory

Merge branch 'rt/cherry-pick-continue-advice-in-status'

* rt/cherry-pick-continue-advice-in-status:
  wt-status: give better advice when cherry-pick is in progress

Merge branch 'nk/config-local-doc'

* nk/config-local-doc:
  config: Add description of --local option

Merge branch 'jk/mergetool-lib-refactor'

Code cleanup.

* jk/mergetool-lib-refactor:
  mergetool--lib: refactor {diff,merge}_cmd logic

Merge branch 'jk/doc-build-move-infordir-def'

Makefile cleanup.

* jk/doc-build-move-infordir-def:
  Documentation/Makefile: move infodir to be with other '*dir's
  Documentation/Makefile: fix spaces around assignments

Merge branch 'fg/submodule-fixup'

Code cleanup.

* fg/submodule-fixup:
  git-submodule.sh: remove duplicate call to set_rev_name

Merge branch 'dk/version-gen-gitdir'

Allow packaging a tarball in a working tree with $GIT_DIR set elsewhere.

* dk/version-gen-gitdir:
  GIT-VERSION-GEN: support non-standard $GIT_DIR path

Merge branch 'dk/maint-t5150-dirname'

Fix a test script.

* dk/maint-t5150-dirname:
  tests: allow sha1's as part of the path

Merge branch 'rs/unpack-trees-tree-walk-conflict-field'

Code clean-up.

* rs/unpack-trees-tree-walk-conflict-field:
  unpack-trees: don't shift conflicts left and right

Merge branch 'rr/rebase-sha1-by-string-query'

Allow various commit objects to be given to "git rebase" by ':/look
for this string' syntax, e.g. "git rebase --onto ':/there'".

* rr/rebase-sha1-by-string-query:
  rebase: use peel_committish() where appropriate
  sh-setup: add new peel_committish() helper
  t/rebase: add failing tests for a peculiar revision

Merge branch 'mm/rm-coalesce-errors'

Give a single message followed by list of paths from "git rm" to
report multiple paths that cannot be removed.

* mm/rm-coalesce-errors:
  rm: introduce advice.rmHints to shorten messages
  rm: better error message on failure for multiple files

Merge branch 'jh/libify-note-handling'

Make it possible to call into copy-notes API from the sequencer code.

* jh/libify-note-handling:
  Move create_notes_commit() from notes-merge.c into notes-utils.c
  Move copy_note_for_rewrite + friends from builtin/notes.c to notes-utils.c
  finish_copy_notes_for_rewrite(): Let caller provide commit message

Merge branch 'fc/sequencer-plug-leak'

Plug a small leak in an error codepath.

* fc/sequencer-plug-leak:
  sequencer: avoid leaking message buffer when refusing to create an empty commit
  sequencer: remove useless indentation

status/commit: make sure --porcelain is not affected by user-facing config

The recent addition of status.branch started affecting what is shown
when "git status --porcelain" is run by mistake.  Identify the
configuration items that should be ignored under "--porcelain"
option, introduce a "deferred config" mechanism to keep the values
read from the configuration, and decide what value to use only after
we read both from configuration and command line.

Signed-off-by: Junio C Hamano <redacted>

commit: make it work with status.short

With "status.short" set, it is now impossible to commit with
status.short set, because it acts like "git commit --short", and it
is impossible to differentiate between a status_format set by the
command-line option parser versus that set by the config parser.

To alleviate this problem, clear status_format as soon as the config
parser has finished its work.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

status: introduce status.branch to enable --branch by default

Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <redacted>
Signed-off-by: Mathieu Lienard--Mayor <redacted>
Reviewed-by: Matthieu Moy <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

status: introduce status.short to enable --short by default

Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <redacted>
Signed-off-by: Mathieu Lienard--Mayor <redacted>
Reviewed-by: Matthieu Moy <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

t/t5528-push-default: test pushdefault workflows

Introduce test_pushdefault_workflows(), and test that all push.default
modes work with central and triangular workflows as expected.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

t/t5528-push-default: generalize test_push_*

The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller, test_push_success(), to optionally accept
a third argument to specify the name of the repository to check for
actual output.  We will use this in the next patch.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

push: change `simple` to accommodate triangular workflows

When remote.pushdefault or branch.<name>.pushremote is set to a
remote that is different from where you usually fetch from (i.e. a
triangular workflow), master@{u} != origin, and push.default is set
to `upstream` or `simple` would fail with this error:

  $ git push
  fatal: You are pushing to remote 'origin', which is not the upstream of
  your current branch 'master', without telling me what to push
  to update which remote branch.

The very name of "upstream" indicates that it is only suitable for
use in central workflows; let us not even attempt to give it a new
meaning in triangular workflows, and error out as before.

However, the `simple` does not have to share this error.  It is
poised to be the default for Git 2.0, and we would like it to do
something sensible in triangular workflows.

Redefine "simple" as "safer upstream" for centralized workflow as
before, but work as "current" for triangular workflow.

We may want to make it "safer current", but that is a separate
issue.

Reported-by: Leandro Lucarella <redacted>
Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

bash prompt: mention that PROMPT_COMMAND mode is faster

__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell.  Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.

Mention this in the comments about setting up the git prompt.

The whole series speeds up the bash prompt on Windows/MSysGit
considerably.  Here are some timing results in three scenarios, each
repeated 10 times:

At the top of the work tree, before:

    $ time for i in {0..9} ; do prompt="$(__git_ps1)" ; done

    real    0m1.716s
    user    0m0.301s
    sys     0m0.772s

  After:

    real    0m0.687s
    user    0m0.075s
    sys     0m0.396s

  After, from $PROMPT_COMMAND:

    $ time for i in {0..9} ; do __git_ps1 '\h:\w' '$ ' ; done

    real    0m0.546s
    user    0m0.075s
    sys     0m0.181s

At the top of the work tree, detached head, before:

    real    0m2.574s
    user    0m0.376s
    sys     0m1.207s

  After:

    real    0m1.139s
    user    0m0.151s
    sys     0m0.500s

  After, from $PROMPT_COMMAND:

    real    0m1.030s
    user    0m0.245s
    sys     0m0.336s

In a subdirectory, during rebase, stash status indicator enabled,
before:

    real    0m3.557s
    user    0m0.495s
    sys     0m1.767s

  After:

    real    0m0.717s
    user    0m0.120s
    sys     0m0.300s

  After, from $PROMPT_COMMAND:

    real    0m0.577s
    user    0m0.047s
    sys     0m0.258s

On Linux the speedup ratio is comparable to Windows, but overall it
was about an order of magnitude faster to begin with.  The last case
from above, repeated 100 times, before:

    $ time for i in {0..99} ; do prompt="$(__git_ps1)" ; done

    real    0m2.806s
    user    0m0.180s
    sys     0m0.264s

  After:

    real    0m0.857s
    user    0m0.020s
    sys     0m0.028s

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: avoid command substitution when finalizing gitstring

Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable.  Spare the overhead
of fork()ing a subshell by using 'printf -v <var>' to directly assign
the output to that variable.

zsh's printf doesn't support the '-v <var>' option, so stick with the
command substitution when under zsh.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: avoid command substitution when checking for untracked files

When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign.  __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.

Avoid this command substitution by additionally passing
'--error-unmatch *', and checking the command's return value.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: use bash builtins to check stash state

When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'.  This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.

However, we don't need to be that thorough for the bash prompt.  We
can omit that verification and only check whether 'refs/stash' exists
or not.  Since 'git pack-refs' never packs 'refs/stash', it's a matter
of checking the existence of a ref file.  Perform this check using
only bash builtins to spare the overhead of fork()+exec()ing a git
process.

Also run 'git pack-refs --all' in the corresponding test to document
that the prompt script depends on 'git pack-refs' not packing
'refs/stash' and to catch possible breakages should this behavior ever
change.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: use bash builtins to check for unborn branch for dirty state

When the dirty work tree and index status indicator is enabled,
__git_ps1() checks for changes in the index by running 'git diff-index
--cached --quiet HEAD --' and looking at its exit code.  However, that
makes sense only when HEAD points to a valid commit: on an unborn
branch the failure of said command would be caused by the invalid
HEAD, not by changes in the index.  Therefore, __git_ps1() first
checks for a valid HEAD by running 'git rev-parse --quiet --verify
HEAD'.

Since the previous patch we implicitly check HEAD's validity by
running 'git rev-parse ... --short HEAD', making the dirty status
indicator's 'git rev-parse' check redundant.  It's sufficient to check
for non-emptyness of the variable holding the abbreviated commit
object name, thereby sparing the overhead of fork()+exec()ing a git
process.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: combine 'git rev-parse' for detached head

When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() now runs the '$(git rev-parse
--short HEAD)' command substitution to get the abbreviated detached
HEAD commit object name.  This imposes the overhead of fork()ing a
subshell and fork()+exec()ing a git process.

Avoid this overhead by combining this command substitution with the
"main" 'git rev-parse' execution for getting the path to the .git
directory & co.  This means that we'll look for the abbreviated commit
object name even when it's not necessary, because we're on a branch or
the detached HEAD can be described.  It doesn't matter, however,
because once 'git rev-parse' is up and running to fulfill all those
other queries, the additional overhead of looking for the abbreviated
commit object name is not measurable because it's lost in the noise.

There is a caveat, however, when we are on an unborn branch, because
in that case HEAD doesn't point to a valid commit, hence the query for
the abbreviated commit object name fails.  Therefore, '--short HEAD'
must be the last options to 'git rev-parse' in order to get all the
other necessary information for the prompt even on an unborn branch.
Furthermore, in that case, and in that case only, 'git rev-parse'
doesn't output the last line containing the abbreviated commit object
name, obviously, so we have to take care to only parse it if 'git
rev-parse' exited without any error.

Although there are tests already excercising __git_ps1() on unborn
branches, they all do so implicitly.  Add a test that checks this
explicitly.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: combine 'git rev-parse' executions in the main code path

There are a couple of '$(git rev-parse --<opt>)' command substitutions
in __git_ps1() and three of them are executed in the main code path:

 - the first to get the path to the .git directory ('--git-dir'),
 - the second to check whether we're inside the .git directory
   ('--is-inside-git-dir'),
 - and the last, depending on the results of the second, either
   * to check whether it's a bare repo ('--is-bare-repository'), or
   * to check whether inside a work tree ('--is-inside-work-tree').

Naturally, this imposes the overhead of fork()ing three subshells and
fork()+exec()ing three git commands.

Combine these four 'git rev-parse' queries into a single one and use
bash parameter expansions to parse the combined output, i.e. to
separate the path to the .git directory from the true/false of
'--is-inside-git-dir', etc.  This way we can eliminate two of the
three subshells and git commands.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: use bash builtins to find out current branch

__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch.  This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.

Since HEAD is in most cases a single-line file and the symbolic ref
format is quite simple to recognize and parse, read and parse it using
only bash builtins, thereby sparing all that fork()+exec() overhead.
Don't display the git prompt if reading HEAD fails, because a readable
HEAD is required for a git repository.  HEAD can also be a symlink
symbolic ref (due to 'core.preferSymlinkRefs'), so use bash builtins
for reading HEAD only when HEAD is not a symlink.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: use bash builtins to find out rebase state

During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/<FILE>)' command
substitution for each.  That is not quite the most efficient way to
read single line single word files, because it imposes the overhead of
fork()ing a subshell and fork()+exec()ing 'cat' several times.

Use the 'read' bash builtin instead to avoid those overheads.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: run 'git rev-parse --git-dir' directly instead of __gitdir()

__git_ps1() finds out the path to the repository by using the
__gitdir() helper function.  __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few shortcuts to recognize a git
repository in cwd or at $GIT_DIR quickly without actually running 'git
rev-parse'.  However, the former two is only necessary for the
completion script but makes no sense for the bash prompt, while the
latter shortcuts are performance optimizations __git_ps1() can do
without (they just avoid the overhead of fork()+exec()ing a git
process).

Run 'git rev-parse --git-dir' directly in __git_ps1(), because it will
allow this patch series to combine several $(git rev-parse ...)
command substitutions in the main code path, and the overall
performance benefit will far outweigh the loss of those few shortcuts
in __gitdir().  Furthermore, since __gitdir() is not needed anymore
for the prompt, remove it from the prompt script finally eliminating
its duplication between the prompt and completion scripts.  Also
remove the comment from the completion script warning about this code
duplication.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: return early from __git_ps1() when not in a git repository

... to gain one level of indentation for the bulk of the function.

(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: print unique detached HEAD abbreviated object name

When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs 'cut -c1-7 .git/HEAD' to
show the 7 hexdigits abbreviated commit object name in the prompt.
Obviously, this neither respects core.abbrev nor produces a unique
object name.

Fix this by using 'git rev-parse --short HEAD' instead and adjust the
corresponding test to use non-standard number of hexdigits.

Signed-off-by: SZEDER Gábor <redacted>

bash prompt: add a test for symbolic link symbolic refs

Signed-off-by: SZEDER Gábor <redacted>

completion, bash prompt: move __gitdir() tests to completion test suite

Currently __gitdir() is duplicated in the git completion and prompt
scripts, while its tests are in the prompt test suite.  This patch
series is about to change __git_ps1() in a way that it won't need
__gitdir() anymore and __gitdir() will be removed from the prompt
script.

So move all __gitdir() tests from the prompt test suite over to the
completion test suite.  Update the setup tests so that they perform
only those steps that are necessary for each test suite.

Signed-off-by: SZEDER Gábor <redacted>

Revert "Merge branch 'jg/status-config'"

This reverts commit 1a22bd31f0a5130ce6c934951a5526ceb774c2be, reversing
changes made to 3e7a5b489e45ae8a3a0b222893d58b172d883136.

It makes it impossible to "git commit" when status.short is set, and
also "git status --porcelain" output is affected by status.branch.

rebase -i: use a better reflog message

Now that the "checkout" invoked internally from "rebase -i" knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better
reflog message when "rebase anotherbranch", "rebase --onto branch",
etc. internally checks out the new fork point.  We will write:

  rebase -i: checkout master

instead of the old

  rebase -i

As all the calls git-rebase--interactive make to underlying git
commands that leave reflog messages are preceded by the internal
comment_for_reflog helper function, which uses the original value of
the GIT_REFLOG_ACTION variable it saw when it first started, the new
assignments to GIT_REFLOG_ACTION actively contaminate the value of
the variable, knowing that it will be reset to a sane value before
it is used again.  This does not generally hold true but it should
suffice for now.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

rebase: use a better reflog message

Now that the "checkout" invoked internally from "rebase" knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better
reflog message when "rebase anotherbranch", "rebase --onto branch",
etc. internally checks out the new fork point.  We will write:

  rebase: checkout master

instead of the old

  rebase

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

config doc: rewrite push.default section

4d35924e (Merge branch 'rr/triangle', 2013-04-07) introduced support
for triangular workflows, but the push.default values still assume
central workflows.

Rewrite the descriptions of `nothing`, `current`, `upstream` and
`matching` for greater clarity, and explicitly explain how they
should behave in triangular workflows.

Leave `simple` as it is for the moment, as we plan to change its
meaning to accommodate triangular workflows in a later patch.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

bash prompt: use 'write_script' helper in interactive rebase test

Helped-by: Jeff King <redacted>
Signed-off-by: SZEDER Gábor <redacted>

bash prompt: fix redirection coding style in tests

Use '>file' instead of '> file', in accordance with the coding
guidelines.

Signed-off-by: SZEDER Gábor <redacted>

Update draft release notes to 1.8.4

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'mz/rebase-tests'

* mz/rebase-tests:
  rebase topology tests: fix commit names on case-insensitive file systems
  tests: move test for rebase messages from t3400 to t3406
  t3406: modernize style
  add tests for rebasing merged history
  add tests for rebasing root
  add tests for rebasing of empty commits
  add tests for rebasing with patch-equivalence present
  add simple tests of consistency across rebase types

Merge branch 'jk/unpack-entry-fallback-to-another'

* jk/unpack-entry-fallback-to-another:
  unpack_entry: do not die when we fail to apply a delta
  t5303: drop "count=1" from corruption dd

Merge branch 'jk/apache-test-for-2.4'

* jk/apache-test-for-2.4:
  lib-httpd/apache.conf: check version only after mod_version loads
  t/lib-httpd/apache.conf: configure an MPM module for apache 2.4
  t/lib-httpd/apache.conf: load compat access module in apache 2.4
  t/lib-httpd/apache.conf: load extra auth modules in apache 2.4
  t/lib-httpd/apache.conf: do not use LockFile in apache >= 2.4

Merge branch 'cm/remote-mediawiki-perlcritique'

* cm/remote-mediawiki-perlcritique: (31 commits)
  git-remote-mediawiki: make error message more precise
  git-remote-mediawiki: add a perlcritic rule in Makefile
  git-remote-mediawiki: add a .perlcriticrc file
  git-remote-mediawiki: clearly rewrite double dereference
  git-remote-mediawiki: fix a typo ("mediwiki" instead of "mediawiki")
  git-remote-mediawiki: put non-trivial numeric values in constants.
  git-remote-mediawiki: don't use quotes for empty strings
  git-remote-mediawiki: replace "unless" statements with negated "if" statements
  git-remote-mediawiki: brace file handles for print for more clarity
  git-remote-mediawiki: modify strings for a better coding-style
  git-remote-mediawiki: put long code into a subroutine
  git-remote-mediawiki: remove import of unused open2
  git-remote-mediawiki: check return value of open
  git-remote-mediawiki: assign a variable as undef and make proper indentation
  git-remote-mediawiki: rename a variable ($last) which has the name of a keyword
  git-remote-mediawiki: remove unused variable $entry
  git-remote-mediawiki: turn double-negated expressions into simple expressions
  git-remote-mediawiki: change the name of a variable
  git-remote-mediawiki: add newline in the end of die() error messages
  git-remote-mediawiki: change style in a regexp
  ...

Merge branch 'bp/remote-mw-tests'

* bp/remote-mw-tests:
  git-remote-mediawiki: remove hardcoded version number in the test suite

Merge branch 'rr/rebase-autostash'

* rr/rebase-autostash:
  rebase: finish_rebase() in noop rebase
  rebase: finish_rebase() in fast-forward rebase
  rebase: guard against missing files in read_basic_state()