gitweb: refer to picon/gravatar images over the same scheme

With the current code, the images from picon and gravatar are
requested over http://, and browsers give mixed contents warning
when gitweb is served over https://.

Just drop the scheme: part from the URL, so that these external
sites are accessed over https:// in such a case.

Signed-off-by: Andrej E Baranov <admin@andrej-andb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
branch: reject -D/-d without branch name

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
branch: give a more helpful message on redundant arguments

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'nd/edit-branch-desc-while-detached' into HEAD

* nd/edit-branch-desc-while-detached:
  branch: no detached HEAD check when editing another branch's description
branch: mark more strings for translation

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: add Python coding guidelines

These are kept short by simply deferring to PEP-8.  Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).

Rationale for version suggestions:

 - Amongst the noise in [1], there isn't any disagreement about using
   2.6 as a base (see also [2]), although Brandon Casey recently added
   support for 2.4 and 2.5 to git-p4 [3].

 - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
   significantly easier [4].

 - Advocating Python 3 support in all scripts is currently unrealistic
   because:

     - 'p4 -G' provides output in a format that is very hard to use with
       Python 3 (and its documentation claims Python 3 is unsupported).

     - Mercurial does not support Python 3.

     - Bazaar does not support Python 3.

 - But we should try to make new scripts compatible with Python 3
   because all new Python development is happening on version 3 and the
   Python community will eventually stop supporting Python 2 [5].

 - Python 3.1 is required to support the 'surrogateescape' error handler
   for encoding/decodng filenames to/from Unicode strings and Python 3.0
   is not longer supported.

[1] http://thread.gmane.org/gmane.comp.version-control.git/210329
[2] http://article.gmane.org/gmane.comp.version-control.git/210429
[3] http://thread.gmane.org/gmane.comp.version-control.git/214579
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://www.python.org/dev/peps/pep-0404/

Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: fix segfault when HEAD points nowhere

After a push of a branch other than the current branch fails in
a no-ff error and if you are still on an unborn branch, the code
recently added to report the failure dereferenced a null pointer
while checking the name of the current branch.

Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gpg: allow translation of more error messages

Mark these strings for translation so that error messages are
printed in the user's language of choice.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gpg: close stderr once finished with it in verify_signed_buffer()

Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run

 git log --show-signature --merges | grep "key"

on the linux kernel git repo. Eventually it will fail with

 error: cannot create pipe for gpg: Too many open files
 error: could not run gpg.

Close the stderr pipe so that this can't happen.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
docs: clarify git-branch --list behavior

It was not clear from the "description" section of git-branch(1)
that using a <pattern> meant that you _had_ to use the --list
option. Let's clarify that, and while we're at it, reword some
clunky and ambiguous sentences.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
branch: let branch filters imply --list

Currently, a branch filter like `--contains`, `--merged`, or
`--no-merged` is ignored when we are not in listing mode.
For example:

  git branch --contains=foo bar

will create the branch "bar" from the current HEAD, ignoring
the `--contains` argument entirely. This is not very
helpful. There are two reasonable behaviors for git here:

  1. Flag an error; the arguments do not make sense.

  2. Implicitly go into `--list` mode

This patch chooses the latter, as it is more convenient, and
there should not be any ambiguity with attempting to create
a branch; using `--contains` and not wanting to list is
nonsensical.

That leaves the case where an explicit modification option
like `-d` is given.  We already catch the case where
`--list` is given alongside `-d` and flag an error. With
this patch, we will also catch the use of `--contains` and
other filter options alongside `-d`.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am: record full index line in the patch used while rebasing

Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end.  While doing so, it used "git diff-tree" but without
giving it the "--full-index" option.

This does not matter for in-repository objects; during rebasing, any
abbreviated object name should uniquely identify them.

But we may be rebasing a commit that contains a change to a gitlink,
in which case we usually should not have the object (it names a
commit in the submodule).  A full object name is necessary to later
reconstruct a fake ancestor index for them.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: simplify build_fake_ancestor()

The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor, 2007-09-17) made the "missing in the
ancestor" case unnecessary, hence sha1_ptr, when used, always points
at the local array.

Get rid of the unneeded variable, and restructure the if/else
cascade a bit to make it easier to read.  There should be no
behaviour change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: diagnose incomplete submodule object name better

"git am -3" uses this function to build a tree that records how the
preimage the patch was created from would have looked like.  An
abbreviated object name on the index line is ordinarily sufficient
for us to figure out the object name the preimage tree would have
contained, but a change to a submodule by definition shows an object
name of a submodule commit which our repository should not have, and
get_sha1_blob() is not an appropriate way to read it (or get_sha1()
for that matter).

Use get_sha1_hex() and complain if we do not find a full object name
there.

We could read from the payload part of the patch to learn the full
object name of the commit, but the primary user "git rebase" has
been fixed to give us a full object name, so this should suffice
for now.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/Makefile: clean up MAN*_TXT lists

We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: avoid poor-man's small caps GIT

In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps.  Later we stopped doing so at around 1.6.5 days.

Let's stop doing so throughout the documentation.  The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git".  And document this in the coding
guideline.

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: the name of the system is 'Git', not 'git'

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: do not use undefined terms git-dir and git-file

We will add gitfile to the glossary in a separate commit.

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: add a description for 'gitfile' to glossary

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: describe the "repository" in repository-layout

Update the introductory part and concisely explain how gitfile is
handled, what it is used for and for what effect.

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