glossary: a revision is just a commit

The current definition of 'revision' sounds like it is saying that a
revision is a tree object.  In reality it is just a commit.

This should be especially useful for people used to other revision
control systems trying to see how familiar concepts translate into git
terms.

Reported-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revisions.txt: clarify the .. and ... syntax

In <rev1>..<rev2> and <rev1>...<rev2>, if either <rev1> or <rev2> is
omitted, it defaults to 'HEAD'.  Add this detail to the document.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: order OPTIONS properly; move <since>..<until>

The OPTIONS section lists <since>..<until> as the first item, but this
is inconsistent with the ordering in SYNOPSIS.  Move it down until it
appears just before [[--] <path>...].

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: generalize <since>..<until>

'<since>..<until>' is misleading, as there are many other forms that
'git log' can accept as an argument.  Replace it with <revision range>,
referring to the section "Specifying Ranges" in revisions.txt, and
rewrite the section appropriately.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: rewrite note on why "--" may be required

In its current form, the note talks about separating options from
"branch names" and "refnames" in the same sentence.  This is entirely
inaccurate, as <revision range> need not be a set of branch names or
ref names.  Rewrite it to use the word "revision range", to be
consistent with the SYNOPSIS.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-shortlog.txt: make SYNOPSIS match log, update OPTIONS

There are broadly two problems with the current SYNOPSIS.  First, it
completely omits the detail that paths can be specified.  Second, it
attempts to list all the options: this is futile as, in addition to
the options unique to it, it accepts all the options that git-rev-list
accepts.  In fixing these problems, make the SYNOPSIS consistent with
that in git-log.txt.  Also add the corresponding sections to OPTIONS.
Save adding the options from rev-list-options.txt for a later patch,
as it requires some work to pick out the options that are relevant to
shortlog.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-multimail: a replacement for post-receive-email

Add git-multimail, a tool for generating notification emails for
pushes to a Git repository.  It is largely plug-in compatible with
post-receive-email, and is proposed to eventually replace that script.
The advantages of git-multimail relative to post-receive-email are
described in README.migrate-from-post-receive-email.

git-multimail is organized in a directory contrib/hooks/git-multimail.
The directory contains:

* git_multimail.py -- a Python module that can generate notification
  emails for pushes to a Git repository.  The file can be used
  directly as a post-receive script (configured via git config
  settings), or it can be imported as a Python module and configured
  via arbitrary Python code.

* README -- user-level documentation for configuring and using
  git-multimail.

* post-receive -- an example of building a post-receive script that
  imports git_multimail.py as a Python module, with an example of how
  to change the email templates.

* README.migrate-from-post-receive-email -- documentation targeted at
  current users of post-receive-email, explaining the differences and
  how to migrate a post-receive-email configuration to git-multimail.

* migrate-mailhook-config -- a script that can migrate a user's
  post-receive-email configuration options to the equivalent
  git-multimail options.

git-multimail is originally derived from post-receive-email and also
incorporates suggestions from the mailing list as well as patches by
the following people:

Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Contributions-by: Chris Hiestand <chrishiestand@gmail.com>
Contributions-by: Michiel Holtkamp <git@elfstone.nl>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
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>
builtin/log.c: make usage string consistent with doc

Replace '<since>..<until>' with '<revision range>', in accordance with
the documentation.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/shortlog.c: make usage string consistent with log

"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates.  In correcting this usage string, make it consistent with
the log_usage string.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'fc/untracked-zsh-prompt' into jch

* fc/untracked-zsh-prompt:
  prompt: fix untracked files for zsh
Merge branch 'jk/receive-pack-deadlocks-with-early-failure' into jch

When receive-pack detects error in the pack header it received in
order to decide which of unpack-objects or index-pack to run, it
returned without closing the error stream, which led to a hang
sideband thread.

* jk/receive-pack-deadlocks-with-early-failure:
  receive-pack: close sideband fd on early pack errors
Merge branch 'tr/line-log' into jch

* tr/line-log:
  git-log(1): remove --full-line-diff description
  line-log: fix documentation formatting
  log -L: improve comments in process_all_files()
  log -L: store the path instead of a diff_filespec
  log -L: test merge of parallel modify/rename
  t4211: pass -M to 'git log -M -L...' test
  log -L: fix overlapping input ranges
  log -L: check range set invariants when we look it up
  Speed up log -L... -M
  log -L: :pattern:file syntax to find by funcname
  Implement line-history search (git log -L)
  Export rewrite_parents() for 'log -L'
  Refactor parse_loc

# Conflicts:
# 	log-tree.c
Merge branch 'jl/submodule-mv' into jch

"git mv A B" when moving a submodule A does "the right thing",
inclusing relocating its working tree and adjusting the paths in
the .gitmodules file.

* jl/submodule-mv:
  rm: delete .gitmodules entry of submodules removed from the work tree
  Teach mv to update the path entry in .gitmodules for moved submodules
  Teach mv to move submodules using a gitfile
  Teach mv to move submodules together with their work trees
Merge branch 'as/check-ignore' into jch

Enhance "check-ignore" (1.8.2 update) to work more like "check-attr"
over bidi-pipes.

The test in the second from the tip needs to be updated; will hold.

* as/check-ignore:
  Documentation: add caveats about I/O buffering for check-{attr,ignore}
  check-ignore: allow incremental streaming of queries via --stdin
  check-ignore: move setup into cmd_check_ignore()
  check-ignore: add -n / --non-matching option
  t0008: remove duplicated test fixture data
Merge branch 'kb/status-ignored-optim-2' into jch

Rerolls kb/status-ignored-optim topic (reverted from 'next').
With help from Karsten, conflicts with as/check-ignore topic have
been sorted out and it is now in 'pu'.

* kb/status-ignored-optim-2:
  dir.c: git-status --ignored: don't scan the work tree twice
  dir.c: git-status --ignored: don't scan the work tree three times
  dir.c: git-status: avoid is_excluded checks for tracked files
  dir.c: replace is_path_excluded with now equivalent is_excluded API
  dir.c: unify is_excluded and is_path_excluded APIs
  dir.c: move prep_exclude
  dir.c: factor out parts of last_exclude_matching for later reuse
  dir.c: git-clean -d -X: don't delete tracked directories
  dir.c: make 'git-status --ignored' work within leading directories
  dir.c: git-status --ignored: don't list empty directories as ignored
  dir.c: git-ls-files --directories: don't hide empty directories
  dir.c: git-status --ignored: don't list empty ignored directories
  dir.c: git-status --ignored: don't list files in ignored directories
  dir.c: git-status --ignored: don't drop ignored directories

# Conflicts:
# 	builtin/check-ignore.c
Merge branch 'jk/remote-helper-with-signed-tags' into jch

Allows remote-helpers to declare they can handle signed tags, and
issue a warning when using those that don't.

* jk/remote-helper-with-signed-tags:
  transport-helper: add 'signed-tags' capability
  transport-helper: pass --signed-tags=warn-strip to fast-export
  fast-export: add --signed-tags=warn-strip mode
Merge branch 'jn/gitweb-install-doc' into jch

Reword gitweb configuration instrutions.

* jn/gitweb-install-doc:
  gitweb/INSTALL: GITWEB_CONFIG_SYSTEM is for backward compatibility
  gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
Merge branch 'fc/transport-helper-error-reporting' into jch

Rerolled with much more clarifications than before.

* fc/transport-helper-error-reporting:
  transport-helper: update remote helper namespace
  transport-helper: trivial code shuffle
  transport-helper: warn when refspec is not used
  transport-helper: clarify pushing without refspecs
  transport-helper: update refspec documentation
  transport-helper: clarify *:* refspec
  transport-helper: improve push messages
  transport-helper: mention helper name when it dies
  transport-helper: report errors properly

# Conflicts:
# 	t/t5801-remote-helpers.sh