gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch

Fixes the encoding for several _plain actions and for text/* and */*+xml blobs.

Signed-off-by: Jürgen Kreileder <jk@blackdown.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Make feed title valid utf8

Properly encode site and project names for RSS and Atom feeds.

Signed-off-by: Jürgen Kreileder <jk@blackdown.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Don't append ';js=(0|1)' to external links

Don't add js parameters to links outside of gitweb itself.

Signed-off-by: Jürgen Kreileder <jk@blackdown.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix broken blob action parameters on blob/commitdiff pages

Fix broken blob action parameters on blobdiff and commitdiff pages by
explicitly passing variables instead of relying on global ones.

(The broken parameters on blob links lead to blob pages which show the
blob but with a hash instead of a commit message and have broken
blob_plain (404 - Cannot find file) and tree links (404 - Reading tree
failed))

Signed-off-by: Jürgen Kreileder <jk@blackdown.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch: rename "no_inline" field

The name of the field invites a misunderstanding that setting it to
false, saying "No, I will not to tell you not to inline", may make
the patch inlined in the body of the message, but that is not what
it does.  The result is still added to the resulting message as a
MIME attachment as long as mime_boundary is set.  This field only
controls if the content disposition of the MIME attachment is set to
"attachment" or "inline".

Rename it to clarify what it is used for.  Besides, a toggle whose
name is "no_frotz" is asking for a double-negation.  Calling it
"disposition-attachment" allows us to naturally read that setting
the field to true to mean "Yes, I want to set content-disposition to
be 'attachment'".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch: --inline-single

Some people may find it convenient to append a simple patch at the
bottom of a discussion e-mail separated by a "scissors" mark, ready
to be applied with "git am -c".  Introduce "--inline-single" option
to format-patch to do so.  A typical usage example might be to start
'f'ollow-up to a discussion, write your message, conclude with "a
patch to do so may look like this.", and then

    \C-u M-! git format-patch --inline-single -1 HEAD <ENTER>

if you are an Emacs user.  Users of other MUA's may want to consult
their manuals to find an equivalent command to append output from an
external command to the message being composed.

It does not make any sense to use this mode when formatting multiple
patches, or to combine this with options such as --attach, --inline,
and --cover-letter, so some of such uses are forbidden.  There may
be more insane combination the check in this patch may not even
bother to reject.  Caveat emptor.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git add <pathspec>... defaults to "-A"

Make "git add <pathspec>..." notice paths that have been removed
from the working tree, i.e. the same as "git add -A <pathspec>...".

Given that "git add <pathspec>" is to update the index with the
state of the named part of the working tree as a whole, it makes it
more intuitive, and also makes it possible to simplify the advice we
give while marking the paths the user finished resolving conflicts
with.  We used to say "to record removal as a resolution, remove the
path from the working tree and say 'git rm'; for all other cases,
edit the path in the working tree and say 'git add'", but we can now
say "update the path in the working tree and say 'git add'" instead.

As promised, this merges the temporary update_files_in_cache() helper
function back to add_files_to_cache() function.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git add: -u/-A now affects the entire working tree

As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without
pathspec, 2013-01-28), in Git 2.0, "git add -u/-A" that is run
without pathspec in a subdirectory updates all updated paths in the
entire working tree, not just the current directory and its
subdirectories.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
core.statinfo: remove as promised in Git 2.0

Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
show-branch.c: update comment style

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch.c: lift all_mask/all_revs to a global static

Also make them and other flags unsigned.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch.c: abstract out "flags" operation

The current code knows how "flags" are used to record reachability
from each "rev" too much.  Move as much knowledge as possible out of
the main traversal logic about commit->object.flags by introducing
wrapper functions.  We still use the higher bits of flags word for
reachability from revs, but eventually we would want to only use the
UNINTERESTING bit to mark common ancestors we do not need to dig
further, and move per-rev bits into commit slabs.
show-branch.c: remove "all_mask"

It is only used at one place, to mask flags that is further masked
with all_revs, which is a proper subset of all_mask, so the use is a
no-op.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch: use commit slab to represent bitflags of arbitrary width

We still haven't lifted the total number of revs limit that is
hardcoded, but the underlying data structure can now represent
arbitrary number of refs.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-ref.c: Add missing call to git_config()

At present, 'git show-ref' ignores any attempt to set config
variables (e.g. core.checkstat) from the command line using
the -c option to git. In order to enable such usage, add the
missing call to git_config() from cmd_show_ref().

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-refs.c: Add missing call to git_config()

At present, 'git pack-refs' ignores any attempt to set config
variables (e.g. core.checkstat) from the command line using
the -c option to git. In order to enable such usage, add the
missing call to git_config() from cmd_pack_refs().

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>