"git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.

* pw/maint-p4-rcs-expansion-newline:
  git p4: RCS expansion should not span newlines

Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* nd/maint-compat-fnmatch-fix:
  compat/fnmatch: fix off-by-one character class's length check

* jh/update-ref-d-through-symref:
  Fix failure to delete a packed ref through a symref
  t1400-update-ref: Add test verifying bug with symrefs in delete_ref()

* esr/maint-doc-fast-import:
  doc/fast-import: clarify how content states are built

* wtk/submodule-doc-fixup:
  git-submodule: wrap branch option with "<>" in usage strings.

The current version contains the sentence:

Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.

which doesn't parse for me; I've changed it to

Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.
Signed-off-by: NMark Szepieniec <mszepien@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: NAntoine Pelisse <apelisse@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

You will get

    $ make distclean 2>&1 | grep curl
    /bin/sh: curl-config: not found
    /bin/sh: curl-config: not found
    /bin/sh: curl-config: not found
    /bin/sh: curl-config: not found
    /bin/sh: curl-config: not found
    $

if you don't have a curl development package installed.

The intent is not to alarm the user, but just to test if there is
a new enough curl installed.  However, if you look at search engine
suggested completions, the above "error" messages are confusing
people into thinking curl is a hard requirement.

Redirect this error output to /dev/null as it is not necessary to be
shown to the end users.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* jk/checkout-out-of-unborn:
  checkout: print a message when switching unborn branches

* cn/config-missing-path:
  config: don't segfault when given --path with a missing value

Fixes an XSS vulnerability in gitweb.

* jk/maint-gitweb-xss:
  gitweb: escape html in rss title

The user can be presented with invalid completion results
when trying to complete a 'git checkout' command.  This can happen
when using a branch name prefix that matches multiple remote branches.

For example, if available branches are:
  master
  remotes/GitHub/maint
  remotes/GitHub/master
  remotes/origin/maint
  remotes/origin/master

When performing completion on 'git checkout ma' the user will be
given the choices:
  maint
  master

However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid.  Furthermore, when
performing completion on 'git checkout mai', no choices will be
suggested.  So, the user is first told that the branch name
'maint' is valid, but when trying to complete 'mai' into 'maint',
that completion is no longer valid.

The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.

The reason for this bug is that the uniq program only
works with sorted input.  The man page states
"uniq prints the unique lines in a sorted file".

When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique.  To do that, it calls 'uniq -u'.  However
the input given to 'uniq -u' is not sorted.

Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
  master
  maint
  master
  maint
  master

which, when passed to 'uniq -u' will remain the same.  Therefore
'maint' will be wrongly suggested as a valid option.

When dealing with 'git checkout mai', the list will be:
  maint
  maint

which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.

A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: NMarc Khouzam <marc.khouzam@gmail.com>
Reviewed-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Character class "xdigit" is the only one that hits 6 character limit
defined by CHAR_CLASS_MAX_LENGTH. All other character classes are 5
character long and therefore never caught by this.

This should make xdigit tests in t3070 pass on Windows.
Reported-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* mg/maint-pull-suggest-upstream-to:
  push/pull: adjust missing upstream help text to changed interface

* mm/maint-doc-commit-edit:
  Document 'git commit --no-edit' explicitly

* as/maint-doc-fix-no-post-rewrite:
  commit: fixup misplacement of --no-post-rewrite description

* rs/lock-correct-ref-during-delete:
  refs: lock symref that is to be deleted, not its target

* rf/maint-mailmap-off-by-one:
  mailmap: avoid out-of-bounds memory access

"git diff -G<pattern>" did not honor textconv filter when looking
for changes.

* jk/maint-diff-grep-textconv:
  diff_grep: use textconv buffers for add/deleted files

Various rfc2047 quoting issues around a non-ASCII name on the From:
line in the output from format-patch have been corrected.

* js/format-2047:
  format-patch tests: check quoting/encoding in To: and Cc: headers
  format-patch: fix rfc2047 address encoding with respect to rfc822 specials
  format-patch: make rfc2047 encoding more strict
  format-patch: introduce helper function last_line_length()
  format-patch: do not wrap rfc2047 encoded headers too late
  format-patch: do not wrap non-rfc2047 headers too early
  utf8: fix off-by-one wrapping of text

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

Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.  A
workaround has been added for this.

* sz/maint-curl-multi-timeout:
  Fix potential hang in https handshake

The refs/replace hierarchy was not mentioned in the
repository-layout docs.

* po/maint-refs-replace-docs:
  Doc repository-layout: Show refs/replace

"git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.

* ph/pull-rebase-detached:
  git-pull: Avoid merge-base on detached head

Update "remote tracking branch" in the documentation to
"remote-tracking branch".

* mm/maint-doc-remote-tracking:
  Documentation: remote tracking branch -> remote-tracking branch

A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM instead.

* rs/branch-del-symref:
  branch: show targets of deleted symrefs, not sha1s
  branch: skip commit checks when deleting symref branches
  branch: delete symref branch, not its target
  branch: factor out delete_branch_config()
  branch: factor out check_branch_commit()

"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.

* nd/grep-true-path:
  grep: stop looking at random places for .gitattributes

"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.

* 'jc/grep-pcre-loose-ends' (early part):
  log --grep: use the same helper to set -E/-F options as "git grep"
  revisions: initialize revs->grep_filter using grep_init()
  grep: move pattern-type bits support to top-level grep.[ch]
  grep: move the configuration parsing logic to grep.[ch]
  builtin/grep.c: make configuration callback more reusable

"git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle it. Work
it around by passing a temporary empty file.

* da/mergetools-p4:
  mergetools/p4merge: Handle "/dev/null"

The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a BEL
output.

* jc/test-say-color-avoid-echo-escape:
  test-lib: Fix say_color () not to interpret \a\b\c in the message

The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.

* bw/config-lift-variable-name-length-limit:
  Remove the hard coded length limit on variable names in config files

When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed. In case of an error however, trying to do
this will cause the program to be killed, as it's pointing to memory
in the stack.

Detect the error and return immediately to avoid freeing or accessing
the uninitialed memory in the stack.
Signed-off-by: NCarlos Martín Nieto <cmn@elego.de>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we switch to a new branch using checkout, we usually output a
message indicating what happened. However, when we switch from an unborn
branch to a new branch, we do not print anything, which may leave the
user wondering what happened.

The reason is that the unborn branch is a special case (see abe19980),
and does not follow the usual switch_branches code path. Let's add a
similar informational message to the special case to match the usual
code path.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The title of an RSS feed is generated from many components,
including the filename provided as a query parameter, but we
failed to quote it.  Besides showing the wrong output, this
is a vector for XSS attacks.
Signed-off-by: NJeff King <peff@peff.net>

Signed-off-by: NEric S. Raymond <esr@thyrsus.com>
Signed-off-by: NJeff King <peff@peff.net>

This bug was introduced in cb585a9c (git-p4: keyword
flattening fixes, 2011-10-16).  The newline character
is indeed special, and $File$ expansions should not try
to match across multiple lines.
Based-on-patch-by: NChris Goard <cgoard@gmail.com>
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJeff King <peff@peff.net>

In case of a missing upstream, the git-parse-remote script suggests:

If you wish to set tracking information for this branch you can do so
with:

    git branch --set-upstream nsiv2 origin/<branch>

But --set-upstream is deprectated. Change the suggestion to:

    git branch --set-upstream-to=origin/<branch> nsiv2
Reported-by: NJeroen van der Ham <vdham@uva.nl>
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJeff King <peff@peff.net>