t1514: Add tests of shortening refnames in strict/loose mode

These tests verify the correct behavior of "git rev-parse --abbrev-ref"
in both "strict" and "loose" modes. Really, it tests the correct behavior
of refs.c:shorten_unambiguous_ref() with its 'strict' argument set to
either true of false.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD"

There is currently a bug in refs.c:shorten_unambiguous_ref() that causes
"refs/remotes/origin/HEAD" to be shortened to "origin/HEAD" instead of
"origin" (which is expected from matching against the "refs/remotes/%.*s"
pattern from refs.c:ref_rev_parse_rules) when it is not a symbolic ref.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin

When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
we use the ref_rev_parse_rules list of expansion patterns. This list
allows "origin" to be expanded into "refs/remotes/origin/HEAD", by
using the "refs/remotes/%.*s/HEAD" pattern from that list.

shorten_unambiguous_ref() exists to provide the reverse operation:
turning a full ref name into a shorter (but still unambiguous) name.
It does so by matching the given refname against each pattern from
the ref_rev_parse_rules list (in reverse), and extracting the short-
hand name from the matching rule.

However, when given "refs/remotes/origin/HEAD" it fails to shorten it
into "origin", because we misuse the sscanf() function when matching
"refs/remotes/origin/HEAD" against "refs/remotes/%.*s/HEAD": We end
up calling sscanf like this:

  sscanf("refs/remotes/origin/HEAD", "refs/remotes/%s/HEAD", short_name)

In this case, sscanf() will match the initial "refs/remotes/" part, and
then match the remainder of the refname against the "%s", and place it
("origin/HEAD") into short_name. The part of the pattern following the
"%s" format is never verified, because sscanf() apparently does not
need to do that (it has performed the one expected format extraction,
and will return 1 correspondingly; see [1] for more details).

This patch replaces the misuse of sscanf() with a fairly simple function
that manually matches the refname against patterns, and extracts the
shorthand name.

[1]: If we assume that sscanf() does not do a verification pass prior
to format extraction, there is AFAICS _no_ way for sscanf() - having
already done one or more format extractions - to indicate to its caller
that the input fails to match the trailing part of the format string.
In other words, AFAICS, the scanf() family of function will only verify
matching input up to and including the last format specifier in the
format string. Any data following the last format specifier will not be
verified. Yet another reason to consider the scanf functions harmful...

Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1514: refname shortening is done after dereferencing symbolic refs

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'fc/fast-export-persistent-marks' into pu

One in the original three-patch series has been found to be faulty
(optimized by rejecting anything but 40-hex as object name
reference, contrary to what has been documented), but kept two
obviously correct optimizations.  The numbers in the log messages
of the remaining changes may become different but I do not expect
it to change that much.

* fc/fast-export-persistent-marks:
  fast-export: don't parse commits while reading marks file
  fast-export: do not parse non-commit objects while reading marks file
Merge branch 'nd/clone-local-with-colon' into pu

* nd/clone-local-with-colon:
  clone: allow cloning local paths with colons in them
Merge branch 'jh/shorten-refname' into pu

* jh/shorten-refname:
  t1514: refname shortening is done after dereferencing symbolic refs
  shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
  t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD"
  t1514: Add tests of shortening refnames in strict/loose mode
Merge branch 'nd/warn-ambiguous-object-name' into pu

* nd/warn-ambiguous-object-name:
  get_sha1: improve ambiguity warning regarding SHA-1 and ref names
Merge branch 'fc/at-head' into pu

Instead of typing four capital letters "HEAD", you can say "@"
instead.

There was another series from Ram that looked mostly test updates
but I lost track of which one was which.  In any case, are people
happy with this series?

* fc/at-head:
  Add new @ shortcut for HEAD
  sha1_name: refactor reinterpret()
  sha1_name: compare variable with constant, not constant with variable
  sha1_name: remove unnecessary braces
  sha1_name: remove no-op
Merge branch 'kb/full-history-compute-treesame-carefully' into pu

Major update to a very core part of the system to improve culling
of irrelevant parents while traversing a mergy history.

Will not be a 1.8.3 material, but is an important topic.

* kb/full-history-compute-treesame-carefully:
  revision.c: treat A...B merge bases as if manually specified
  revision.c: discount side branches when computing TREESAME
  simplify-merges: drop merge from irrelevant side branch
  simplify-merges: never remove all TREESAME parents
  t6012: update test for tweaked full-history traversal
  revision.c: Make --full-history consider more merges
  rev-list-options.txt: correct TREESAME for P
  t6111: allow checking the parents as well
  t6111: new TREESAME test set
  t6019: test file dropped in -s ours merge
  decorate.c: compact table when growing
Merge branch 'jk/gitweb-utf8' into pu

Various fixes to gitweb.

* jk/gitweb-utf8:
  gitweb: Fix broken blob action parameters on blob/commitdiff pages
  gitweb: Don't append ';js=(0|1)' to external links
  gitweb: Make feed title valid utf8
  gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch
Merge branch 'jc/format-patch' into pu

A new option to send a single patch to the standard output to be
appended at the bottom of a message.  I personally have no need for
this, but it was easy enough to cobble together.  Tests, docs and
stripping out more MIMEy stuff are left as exercises to interested
parties.

* jc/format-patch:
  format-patch: --inline-single
  format-patch: rename "no_inline" field

# Conflicts:
# 	pretty.c
Merge branch 'jk/commit-info-slab' into pu

Technology demonstration to show a way we could use unbound number
of flag bits on commit objects.

* jk/commit-info-slab:
  commit-slab: introduce a macro to define a slab for new type
  commit-slab: avoid large realloc
  commit: allow associating auxiliary info on-demand
Merge branch 'mg/more-textconv' into pu

Rerolled. I am not sure if I like "show <blob>" and "grep" that use
textconv by default, though.

* mg/more-textconv:
  git grep: honor textconv by default
  grep: honor --textconv for the case rev:path
  grep: allow to use textconv filters
  t7008: demonstrate behavior of grep with textconv
  cat-file: do not die on --textconv without textconv filters
  show: honor --textconv for blobs
  t4030: demonstrate behavior of show with textconv
Merge branch 'mh/multimail' into pu

$gmane/223564

* mh/multimail:
  git-multimail: a replacement for post-receive-email