* maint-1.7.11:
  Almost 1.7.11.6
  gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO
  rebase -i: use full onto sha1 in reflog
  sh-setup: protect from exported IFS
  receive-pack: do not leak output from auto-gc to standard output
  t/t5400: demonstrate breakage caused by informational message from prune
  setup: clarify error messages for file/revisions ambiguity
  send-email: improve RFC2047 quote parsing
  fsck: detect null sha1 in tree entries
  do not write null sha1s to on-disk index
  diff: do not use null sha1 as a sentinel value

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

The reflog entries left by "git rebase" and "git rebase -i" were
inconsistent (the interactive one gave an abbreviated object name).

* mg/rebase-i-onto-reflog-in-full:
  rebase -i: use full onto sha1 in reflog

When the user exports a non-default IFS without HT, scripts that
rely on being able to parse "ls-files -s | while read a b c..."
start to fail.  Protect them from such a misconfiguration.

* jc/maint-protect-sh-from-ifs:
  sh-setup: protect from exported IFS

When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.

* bc/receive-pack-stdout-protection:
  receive-pack: do not leak output from auto-gc to standard output
  t/t5400: demonstrate breakage caused by informational message from prune

"git diff" had a confusion between taking data from a path in the
working tree and taking data from an object that happens to have
name 0{40} recorded in a tree.

* jk/maint-null-in-trees:
  fsck: detect null sha1 in tree entries
  do not write null sha1s to on-disk index
  diff: do not use null sha1 as a sentinel value

"git send-email" did not unquote encoded words that appear on the
header correctly, and lost "_" from strings.

* tr/maint-send-email-2047:
  send-email: improve RFC2047 quote parsing

When the user gives an argument that can be taken as both a
revision name and a pathname without disambiguating with "--", we
used to give a help message "Use '--' to separate".  The message
has been clarified to show where that '--' goes on the command
line.

* mm/die-with-dashdash-help:
  setup: clarify error messages for file/revisions ambiguity

"gitweb" when used with PATH_INFO failed to notice directories with
SP (and other characters that need URL-style quoting) in them.

* js/gitweb-path-info-unquote:
  gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO

* maint-1.7.11:
  Prepare for 1.7.11.6
  Make the ciabot scripts completely self-configuring in the normal case.
  Improved documentation for the ciabot scripts.
  man: git pull -r is a short for --rebase
  gitcli: describe abbreviation of long options
  rev-list docs: clarify --topo-order description
  Documentation/CodingGuidelines: spell out more shell guidelines
  Documentation: do not mention .git/refs/* directories
  tests: Introduce test_seq

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

A minor documentation update.

* mv/pull-r-for-rebase:
  man: git pull -r is a short for --rebase

We did not document that many commands take unique prefix
abbreviations of long options (e.g. "--option" may be the only flag
that the command accepts that begin with "--opt", in which case you
can give "--opt") anywhere easy to find for new people.

* jc/maint-abbrev-option-cli:
  gitcli: describe abbreviation of long options

It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".

* jc/maint-rev-list-topo-doc:
  rev-list docs: clarify --topo-order description

In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.

* hv/coding-guidelines:
  Documentation/CodingGuidelines: spell out more shell guidelines

Our documentation used to assume having files in .git/refs/*
directories was the only to have branches and tags, but that is not
true for quite some time.

* jc/tag-doc:
  Documentation: do not mention .git/refs/* directories

Add a compatibility/utility function to the test framework.

* mk/test-seq:
  tests: Introduce test_seq

* lp/no-cmd-http-fetch:
  builtin.h: remove unused cmd_<foo> declarations

* bw/maint-1.7.9-solaris-getpass:
  Enable HAVE_DEV_TTY for Solaris
  terminal: seek when switching between reading and writing

* jk/maint-commit-check-committer-early:
  commit: check committer identity more strictly

Signed-off-by: NEric S. Raymond <esr@thyrsus.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NEric S. Raymond <esr@thyrsus.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.7.11:
  contrib/ciabot: Get ciabot configuration from git variables

These changes remove all need to modify the ciabot scripts for installation.
Instead, per-project configuration can be dome via variables in a [ciabot]
section of the config file.

Also, correct for the new server address.
Signed-off-by: NEric S. Raymond <esr@thyrsus.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* 'jc/doc-git-updates' (early part):
  Documentation: update URL for formatted pages

The one at kernel.org has not been updated for quite a while and
can no longer be called "the latest".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Letting the "--rebase" option squat on the short-and-sweet single
letter option "-r" was an unintended accident and was not even
documented, but the short option seems to be already used in the
wild. Let's document it so that other options that begin with "r"
would not be tempted to steal it.
Signed-off-by: NMiklos Vajna <vmiklos@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* git://github.com/git-l10n/git-po:
  l10n: Fixes to Swedish translation

Tersify texts overflowing an 80-character terminal.
Fix spelling mistakes.
Signed-off-by: NPeter Krefting <peter@softwolves.pp.se>

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

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

* rj/maint-grep-remove-redundant-test:
  t7810-*.sh: Remove redundant test

* hv/link-alt-odb-entry:
  link_alt_odb_entry: fix read over array bounds reported by valgrind

It was unclear what "--topo-order" was really about in the
documentation.  It is not just about "children before parent", but
also about "don't mix lineages".

Reword the description for both "--date-order" and "--topo-order",
and add an illustration to it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When gitweb is used as a DirectoryIndex, it attempts to strip
PATH_INFO on its own, as $cgi->url() fails to do so.

However, it fails to account for the fact that PATH_INFO has
already been URL-decoded by the web server, but the value
returned by $cgi->url() has not been. This causes the stripping
to fail whenever the URL contains encoded characters.

To see this in action, setup gitweb as a DirectoryIndex and
then use it on a repository with a directory containing a
space in the name. Navigate to tree view, examine the gitweb
generated html and you'll see a link such as:

  <a href="/test.git/tree/HEAD:/directory with spaces">directory with spaces</a>

When clicked on, the browser will URL-encode this link, giving
a $cgi->url() of the form:

   /test.git/tree/HEAD:/directory%20with%20spaces

While PATH_INFO is:

   /test.git/tree/HEAD:/directory with spaces

Fix this by calling unescape() on both $my_url and $my_uri before
stripping PATH_INFO from them.
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Acked-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.

Spell some of the guidelines out.
Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.

This memoization can cause problems, e.g consider the following case:

SVN repo:

  ... - a - b - c - m  <- trunk
          \        /
            d  -  e    <- branch1

The Git import of the above repo is at commit 'a' and doesn't know about
the branch1. In case of an 'git svn rebase', only the trunk of the
SVN repo is imported. During the creation of the git commit 'm', git svn
uses the svn:mergeinfo property and tries to find the corresponding git
commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
only imports the current branch so commit 'e' is not imported.
Therefore git svn fails to create commit 'm' as a merge commit, because one
of its parents is not known to git. The imported history looks like this:

  ... - a - b - c - m  <- trunk

A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
to add 'e' as a parent and to make it a real git merge commit, because it
was already imported.

That's why the imported history misses the merge and looks like this:

  ... - a - b - c - m  <- trunk
          \
            d  -  e    <- branch1

Right now the only known workaround for importing 'm' as a merge is to
force reimporting 'm' again from SVN, e.g. via

  $ git svn reset --revision $(git find-rev $c)
  $ git svn fetch

Sadly, this is where the behavior has regressed: git svn reset doesn't
invalidate the old mergeinfo cache, which is no longer valid for the
reimport, which leads to 'm' beeing imprted with only 'c' as parent.

As solution to this problem, this commit invalidates the mergeinfo cache
to force correct recalculation of the parents.

During development of this patch, several ways for invalidating the cache
where considered. One of them is to use Memoize::flush_cache, which will
call the CLEAR method on the underlying Memoize persistency implementation.
Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
introduced in 68f532f4 could optionally be used implement the
CLEAR method, so this is not an option.

Reseting the internal hash used to store the memoized values has the same
problem, because it calls the non-existing CLEAR method of the
underlying persistency layer, too.

Considering this and taking into account the different implementations
of the memoization modules, where Memoize::Storable is not in our control,
implementing the missing CLEAR method is not an option, at least not if
Memoize::Storable is still used.

Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and contain wrong data. Fortunately, the
memoization is active in memory only for a small portion of the code.
Invalidating the cache by deleting the files on disk if it isn't active
should be safe.
Signed-off-by: NPeter Baumann <waste.manager@gmx.de>
Signed-off-by: NSteven Walter <stevenrwalter@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>