Documentation: clarify 'ours' merge strategy

Make it clear in the docs that the merge takes the tree of HEAD and
ignores everything in the other branches.  This should hopefully clear
up confusion, usually caused by the user looking for a strategy that
resolves all conflict hunks in favour of HEAD (which is completely
different and currently not supported).

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update 'git remote update' usage string to match man page.

Commit b344e161 taught 'git remote update' to understand
[group | remote] as its argument.  The man page was updated
to document this change, but the usage string was not.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-add.txt: fix formatting of --patch section

remote: fix use-after-free error detected by glibc in ref_remove_duplicates

In ref_remove_duplicates, when we encounter a duplicate and remove it
from the list we need to make sure that the prev pointer stays
pointing at the last entry and also skip over adding the just freed
entry to the string_list.

Previously fetch could crash with:
*** glibc detected *** git: corrupted double-linked list: ...

Also add a test to try and catch problems with duplicate removal in
the future.

Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: Ensure rpm packages can be read by older rpm versions

The kernel.org hosts where the packages are built are now using Fedora
11, which defaults to sha256 for file digests instead of md5.  Older
versions of rpm can not handle these packages.  Tell rpmbuild to use md5
file digests for better compatibility.

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

bash: add the merge option --ff-only

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Make 'history' view (re)use git_log_generic()

Make git_history use git_log_generic, passing git_history_body as one
of its paramaters.  This required changes to git_log_generic, in
particular passing more things as parameters.

While refactoring common code of 'log', 'shortlog' and 'history' view,
we did unify pagination, using always the form used by 'history' view,
namely
  first * prev * next
in place of
  HEAD * prev * next
used by 'log' and 'shortlog' views.

The 'history' view now supports commit limiting via 'hpb' parameter,
similarly to 'shortlog' (and 'log') view.  Performance of 'history'
view got improved a bit, as it doesn't run git_get_hash_by_path for
"current" version in a loop.  Error detection and reporting for
'history' view changed a bit.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Refactor common parts of 'log' and 'shortlog' views

Put the common parts of git_log and git_shortlog into git_log_generic
subroutine: git_log and git_shortlog are now thin wrappers calling
git_log_generic with appropriate arguments.

The unification of code responsible for 'log' and 'shorlog' actions
lead to the following changes in gitweb output
 * 'tree' link in page_nav now uses $hash parameter, as was the case
   for 'shortlog' but not for 'log'
 * 'log' view now respect $hash_parent limiting, like 'shortlog' did
 * 'log' view doesn't have special case for empty list anymore, and it
   always uses page_header linking to summary view, like 'shortlog'
   did.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Refactor 'log' action generation, adding git_log_body()

Put the main part of 'log' view generation into git_log_body,
similarly how it is done for 'shortlog' and 'history' views (and
also for 'tags' and 'heads' views).

This is preparation for extracting common code between 'log',
'shortlog' and 'history' actions.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git svn: add authorsfile test case for ~/.gitconfig

The commit for:
    git svn: read global+system config for clone+init

Initially lacked a test case because the author was unable to
reproduce it under his test environment, this adds it.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git svn: read global+system config for clone+init

Since $GIT_DIR does not exist when initializing new repositories,
we can follow back to the global and system config files for
git.

The logic for this was originally introduced when
$GIT_DIR/config was the only config file git could read (back
when "git config" was "git repo-config"), so the function is
renamed to "read_git_config" instead of "read_repo_config".

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git svn: handle SVN merges from revisions past the tip of the branch

When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from.  When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.

In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.

[ew: This includes the following (squashed) commit to prevent
     errors during bisect:]

  Author: Toby Allsopp <toby.allsopp@navman.co.nz>
  Date:   Fri Nov 13 09:48:39 2009 +1300

    git-svn: add (failing) test for SVN 1.5+ merge with intervening commit

    This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
    properties.  The problematic case is when there is some commit on an
    unrelated branch after the last commit on the merged-from branch.
    When SVN records the mergeinfo property, it records the latest
    revision in the whole repository, which, in the problematic case, is
    not on the branch it is merging from.

    To trigger the git-svn bug, we modify t9151 to include two SVN merges,
    the second of which has an intervening commit.  The SVN dump was
    generated using SVN 1.6.6 (on Debian squeeze amd64).

Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-add.txt: fix formatting of --patch section

Extra paragraphs should be prefixed with a plus sign.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-backend: Fix bad treatment of uintmax_t in Content-Length

Our Content-Length needs to report an off_t, which could be larger
precision than size_t on this system (e.g. 32 bit binary built with
64 bit large file support).

We also shouldn't be passing a size_t parameter to printf when
we've used PRIuMAX as the format specifier.

Fix both issues by using uintmax_t for the hdr_int() routine,
allowing strbuf's size_t to automatically upcast, and off_t to
always fit.

Also fixed the copy loop we use inside of send_local_file(), we never
actually updated the size variable so we might as well not use it.

Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

give priority to progress messages

In theory it is possible for sideband channel #2 to be delayed if
pack data is quick to come up for sideband channel #1.  And because
data for channel #2 is read only 128 bytes at a time while pack data
is read 8192 bytes at a time, it is possible for many pack blocks to
be sent to the client before the progress message fifo is emptied,
making the situation even worse.  This would result in totally garbled
progress display on the client's console as local progress gets mixed
with partial remote progress lines.

Let's prevent such situations by giving transmission priority to
progress messages over pack data at all times.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Provide a build time default-pager setting

Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.

Examples:

On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.

On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Provide a build time default-editor setting

Provide a DEFAULT_EDITOR knob to allow setting the fallback
editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR
are unset).  The value can be set at build time according to a
system’s policy.  For example, on Debian systems, the default
editor should be the 'editor' command.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am -i, git-svn: use "git var GIT_PAGER"

Use the new "git var GIT_PAGER" command to ask what pager to use.

Without this change, the core.pager configuration is ignored by
these commands.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"

Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere.  This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach git var about GIT_PAGER

Expose the command found by setup_pager() for scripts to use.
Scripts can use this to avoid repeating the logic to look for a
proper pager in each command.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach git var about GIT_EDITOR

Expose the command used by launch_editor() for scripts to use.
This should allow one to avoid searching for a proper editor
separately in each command.

git_editor(void) uses the logic to decide which editor to use
that used to live in launch_editor().  The function returns NULL
if there is no suitable editor; the caller is expected to issue
an error message when appropriate.

launch_editor() uses git_editor() and gives the error message the
same way as before when EDITOR is not set.

"git var GIT_EDITOR" gives the editor name, or an error message
when there is no appropriate one.

"git var -l" gives GIT_EDITOR=name only if there is an
appropriate editor.

Originally-submitted-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Suppress warnings from "git var -l"

For scripts using "git var -l" to read all logical variables at
once, not all per-variable warnings will be relevant.  So suppress
them.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Do not use VISUAL editor on dumb terminals

Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb".  Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.

vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme).  git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update packfile transfer protocol documentation

The current technical documentation for the packfile protocol is both
sparse and incorrect.  This documents the fetch-pack/upload-pack and
send-pack/ receive-pack protocols much more fully.

Add documentation from Shawn's upcoming http-protocol docs that is
shared by the packfile protocol. protocol-common.txt describes ABNF
notation amendments, refname rules and the packet line format.

Add documentation on the various capabilities supported by the
upload-pack and receive-pack protocols. protocol-capabilities.txt
describes multi-ack, thin-pack, side-band[-64k], shallow, no-progress,
include-tag, ofs-delta, delete-refs and report-status.

Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: nearest-ancestor rewriting outside subdir filter

Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.

However, that rewriting strategy is also a useful building block in
other tasks.  For example, if you want to split out a subset of files
from your history, you would typically call

  git filter-branch -- <refs> -- <files>

But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.

The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: stop special-casing $filter_subdir argument

Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.

Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in

  git filter-branch --subdirectory-filter subdir -- --all -- subdir/file

an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.

To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args.  The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.

An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).

Thanks to Johannes Sixt for suggesting this solution.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  check-ref-format -h: it does not know the --print option yet

... but it does on the 'master' branch.

check-ref-format -h: it does not know the --print option yet

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

git-describe.txt: formatting fix

A multi-line SYNOPSIS description must be marked as [verse]

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

Merge branch 'maint'

* maint:
  merge: do not setup worktree twice
  check-ref-format: update usage string

Conflicts:
builtin-check-ref-format.c

Merge branch 'jk/maint-format-patch-p-suppress-stat'

* jk/maint-format-patch-p-suppress-stat:
  format-patch: make "-p" suppress diffstat

Merge branch 'pb/maint-gitweb-blob-lineno'

* pb/maint-gitweb-blob-lineno:
  gitweb: Fix blob linenr links in pathinfo mode

Merge branch 'tr/describe-advice'

* tr/describe-advice:
  describe: when failing, tell the user about options that work

Merge branch 'jk/maint-1.6.3-ls-files-i'

* jk/maint-1.6.3-ls-files-i:
  ls-files: unbreak "ls-files -i"

Merge branch 'bg/merge-ff-only'

* bg/merge-ff-only:
  Teach 'git merge' and 'git pull' the option --ff-only

Merge branch 'vl/maint-openssl-signature-change'

* vl/maint-openssl-signature-change:
  imap-send.c: fix compiler warnings for OpenSSL 1.0

Merge branch 'jk/maint-push-config'

* jk/maint-push-config:
  push: always load default config

Merge branch 'jk/gitignore-anchored'

* jk/gitignore-anchored:
  gitignore: root most patterns at the top-level directory

Conflicts:
.gitignore

Merge branch 'jp/dirty-describe'

* jp/dirty-describe:
  Teach "git describe" --dirty option

Merge branch 'sr/blame-incomplete'

* sr/blame-incomplete:
  blame: make sure that the last line ends in an LF

diff --no-index: make the usage string less scary

Start the diff --no-index usage string with "usage:" instead of
"fatal:".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-{recursive,subtree}: use usagef() to print usage

Usage messages (for example, from "git merge-recursive -h") are
friendlier when not preceded by "fatal".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Introduce usagef() that takes a printf-style format

Some new callers would want to use printf-like formatting, when issuing
their usage messages.  An option is to change usage() itself also be like
printf(), which would make it similar to die() and warn().

But usage() is typically fixed, as opposed to die() and warn() that gives
diagnostics depending on the situation.  Indeed, the majority of strings
given by existing callsites to usage() are fixed strings.  If we were to
make usage() take printf-style format, they all need to be changed to have
"%s" as their first argument.

So instead, introduce usagef() so that limited number of callers can use
it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Let 'git <command> -h' show usage without a git dir

There is no need for "git <command> -h" to depend on being inside
a repository.

Reported by Gerfried Fuchs through http://bugs.debian.org/462557

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git http-push -h'

http-push already knows how to dump usage if it is given no options, but
it interprets '-h' as the URL to a remote repository:

    $ git http-push -h
    error: Cannot access URL -h/, return code 6

Dump usage instead.  Humans wanting to pass the URL -h/ to curl for some
reason can use 'git http-push -h/' explicitly.  Scripts expecting to
access an HTTP repository at URL '-h' will break, though.

Also delay finding a git directory until after option parsing, so
"http-push -h" can be used outside any git repository.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: Add "--no-stat" as a synonym for "-p"

"-p" means "generate patch" in 'git log' and 'git diff', so it's
quite surprising that it means "suppress diffstat" in
'git format-patch'.

Keep the "-p" option for backward compatibility, but add
"--no-stat" as a more intuitive synonym. For backward compatibility
with scripts, we must allow combinations of --stat and --no-stat.

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch documentation: Fix formatting

Format git commands and options consistently using back quotes
(i.e. a fixed font in the resulting HTML document).

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch documentation: Remove diff options that are not useful

To simplify reading the documentation for format-patch, remove the
description of common diff options that are not useful for the
purpose of the command (i.e. "Prepare patches for e-mail submission").

Specifically, this removes the description of the following options:

  --raw
  -z
  --color
  --no-color
  --color-words
  --diff-filter
  -S
  --pickaxe-all
  --pickaxe-regex
  -R
  --relative
  --exit-code
  --quiet

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: Always generate a patch

Jeff King recently reinstated -p to suppress the default diffstat
(as -p used to work before 68daa64, about 14 months ago).

However, -p is also needed in combination with certain options
(e.g. --stat or --numstat) in order to produce any patch at all.
The documentation does not mention this.

Since the purpose of format-patch is to produce a patch that
can be emailed, it does not make sense that certain combination
of options will suppress the generation of the patch itself.

Therefore:

* Update 'git format-patch' to always generate a patch.

* Since the --name-only, --name-status, and --check suppresses
  the generation of the patch, disallow those options,
  and remove the description of them in the documentation.

* Remove the reference to -p in the description of -U.

* Remove the descriptions of the options that are synonyms for -p
  plus another option (--patch-with-raw and --patch-with-stat).

* While at it, slightly tweak the description of -p itself
  to say that it generates "plain patches", so that you can
  think of -p as "plain patch" as an mnemonic aid.

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Let 'git http-fetch -h' show usage outside any git repository

Delay search for a git directory until option parsing has finished.
None of the functions used in option parsing look for or read any
files other than stdin, so this is safe.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jn/maint-http-fetch-mingw' into jn/help-everywhere

* jn/maint-http-fetch-mingw:
  http-fetch: add missing initialization of argv0_path
  merge: do not setup worktree twice
  check-ref-format: update usage string

Conflicts:
builtin-check-ref-format.c

Show usage string for 'git stripspace -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git unpack-file -h'

"unpack-file -h" could be asking to save the contents of a blob
named "-h".  Strictly speaking, such a pathological ref name is
possible, but the user would have to had said something like
"tags/-h" to name such a pathological ref already.  When used in
scripts, unpack-file is typically not passed a user-supplied tag
name directly.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git show-index -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git rev-parse -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git merge-one-file -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git mailsplit -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git imap-send -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git get-tar-commit-id -h'

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git fast-import -h'

Let "git fast-import -h" (with no other arguments) print usage
before exiting, even when run outside any repository.

Cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git check-ref-format -h'

This only changes the behavior of "git check-ref-format -h"
without any other options and arguments.

This change cannot be breaking backward compatibility, since any
valid refname must contain a /.   Most existing scripts use
arguments such as "heads/$foo".  If some script checks the
refname "-h" alone, git check-ref-format will still exit with
nonzero status, and the only detrimental side-effect will be a
usage string sent to stderr.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-fetch: add missing initialization of argv0_path

According to c6dfb39 (remote-curl: add missing initialization of
argv0_path, 2009-10-13), programs with "main" must call this to
work correctly on MinGW.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge: do not setup worktree twice

Builtins do not need to run setup_worktree() for themselves, since
the builtin machinery runs it for them.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

check-ref-format: update usage string

'git check-ref-format' has learned --branch and --print options
since the usage string was last updated.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-update-index.txt: Document the --really-refresh option.

Add the description next to --assume-unchanged because this option is only
useful in a special case of using that option.

Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git show-ref -h'

This only changes the behavior of "git show-ref -h" without any
other options and arguments.

"show-ref -h" currently is short for "show-ref --head", which
shows all the refs/* and HEAD, as opposed to "show-ref" that
shows all the refs/* and not HEAD.

Does anybody use "show-ref -h"?  It was in Linus's original, most
likely only because "it might be handy", not because "the command
should not show the HEAD by default for such and such reasons".
So I think it is okay if "show-ref -h" (but not "show-ref
--head") gives help and exits.

If a current script uses "git show-ref -h" without any other
arguments, it would have to be adapted by changing "-h" to
"--head".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git merge-ours -h'

This change is strictly about 'git merge-ours -h' without
any other options and arguments.

This change cannot break compatibility since merge drivers are
always passed '--', among other arguments.

Any usage string for this command is a lie, since it ignored its
arguments until now.  Still, it makes sense to let the user know
the expected usage when asked.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git commit-tree -h'

Treat an "-h" option as a request for help, rather than a "Not a
valid object name" error.

"commit-tree -h" could be asking to create a new commit from a
treeish named "-h".  Strictly speaking, such a pathological ref
name is possible, but the user would have to had said something
like "tags/-h" to name such a pathological already.  commit-tree
is usually used in scripts with raw object ids, anyway.

For consistency, the "-h" option uses its new meaning even if
followed by other arguments.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git cherry -h'

Treat an "-h" option as a request for help, rather than an
"Unknown commit -h" error.

"cherry -h" could be asking to compare histories that leads to
our HEAD and a commit that can be named as "-h".  Strictly
speaking, that may be a valid refname, but the user would have to
say something like "tags/-h" to name such a pathological ref
already, so it is not such a big deal.

The "-h" option keeps its meaning even if preceded by other
options or followed by other arguments.  This keeps the
command-line syntax closer to what parse_options would give and
supports shell aliases like 'alias cherry="git cherry -v"' a
little better.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Show usage string for 'git grep -h'

Clarification: the following description only talks about "git
grep -h" without any other options and arguments.

Such a change cannot be breaking backward compatibility.  "grep
-h" cannot be asking for suppressing filenames, as there is no
match pattern specified.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Retire fetch--tool helper to contrib/examples

When git-fetch was builtin-ized, the previous script was moved to
contrib/examples.  Now, it is the sole remaining user for
'git fetch--tool'.

The fetch--tool code is still worth keeping around so people can
try out the old git-fetch.sh, for example when investigating
regressions from the builtinifaction.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5551-http-fetch: Work around broken Accept header in libcurl

Unfortunately at least one version of libcurl has a bug causing
it to include "Accept: */*" in the same POST request where we have
already asked for "Accept: application/x-git-upload-pack-response".

This is a bug in libcurl, not Git, or our test vector.  The
application has explicitly asked the server for a single content
type, but libcurl has mistakenly also told the server the client
application will accept */*, which is any content type.

Based on the libcurl change log, this "Accept: */*" header bug
may have been fixed in version 7.18.1 released March 30, 2008:

  http://curl.haxx.se/changes.html#7_18_1

Rather than require users to upgrade libcurl we change the test
vector to trim this line out of the 2nd request.

Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5551-http-fetch: Work around some libcurl versions

Some versions of libcurl report their output when GIT_CURL_VERBOSE
is set differently than other versions do.  At least one variant
(version unknown but likely pre-7.18.1) reports the POST payload to
stderr, and omits the blank line after each HTTP request/response.
We clip these lines out of the stderr output now before doing the
compare, so we aren't surprised by this trivial difference.

Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-backend: Protect GIT_PROJECT_ROOT from /../ requests

Eons ago HPA taught git-daemon how to protect itself from /../
attacks, which Junio brought back into service in d79374c7b58d
("daemon.c and path.enter_repo(): revamp path validation").

I did not carry this into git-http-backend as originally we relied
only upon PATH_TRANSLATED, and assumed the HTTP server had done
its access control checks to validate the resolved path was within
a directory permitting access from the remote client.  This would
usually be sufficient to protect a server from requests for its
/etc/passwd file by http://host/smart/../etc/passwd sorts of URLs.

However in 917adc036086 Mark Lodato added GIT_PROJECT_ROOT as an
additional method of configuring the CGI.  When this environment
variable is used the web server does not generate the final access
path and therefore may blindly pass through "/../etc/passwd"
in PATH_INFO under the assumption that "/../" might have special
meaning to the invoked CGI.

Instead of permitting these sorts of malformed path requests, we
now reject them back at the client, with an error message for the
server log.  This matches git-daemon behavior.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git-aware CGI to provide dumb HTTP transport

http-backend: Fix symbol clash on AIX 5.3

Mike says:

 > > +static void send_file(const char *the_type, const char *name)
 > > +{
 >
 > I think a symbol clash here is responsible for a build breakage in
 > next on AIX 5.3:
 >
 > CC http-backend.o
 > http-backend.c:213: error: conflicting types for `send_file'
 > /usr/include/sys/socket.h:676: error: previous declaration of `send_file'
 > gmake: *** [http-backend.o] Error 1

So we rename the function send_local_file().

Reported-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Add intermediate build products to .gitignore

MSVC: Add support for building with NO_MMAP

When the NO_MMAP build variable is set, the msvc linker complains:

    error LNK2001: unresolved external symbol _getpagesize

The msvc libraries do not define the getpagesize() function,
so we move the mingw_getpagesize() implementation from the
conditionally built win32mmap.c file to mingw.c.

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

Makefile: keep MSVC and Cygwin configuration separate

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

Makefile: merge two Cygwin configuration sections into one

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

Add intermediate build products to .gitignore

Temporaries such as configure.ac+ and Documentation/*.xml+
sometimes remain after an interrupted build.  Tell git not to
track them.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: make "-p" suppress diffstat

Once upon a time, format-patch would use its default stat
plus patch format only when no diff format was given on the
command line. This meant that "format-patch -p" would
suppress the stat and show just the patch.

Commit 68daa64 changed this to keep the stat format when we
had an "implicit" patch format, like "-U5". As a side
effect, this meant that an explicit patch format was now
ignored (because cmd_format_patch didn't know the reason
that the format was set way down in diff_opt_parse).

This patch unbreaks what 68daa64 did (while still preserving
what 68daa64 was trying to do), reinstating "-p" to suppress
the default behavior. We do this by parsing "-p" ourselves
in format-patch, and noting whether it was used explicitly.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log --format: don't ignore %w() at the start of format string

This fixes e.g. --format='%w(72)%s'.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pre-commit.sample: Diff against the empty tree when HEAD is invalid

This was already the case for the old "diff --check" call, but the new
one that checks whether there are any non-ascii file names was missing
it, making that check fail for root commits.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/commit-s-subject-is-not-a-footer'

* jc/commit-s-subject-is-not-a-footer:
  builtin-commit.c: fix logic to omit empty line before existing footers

builtin-commit.c: fix logic to omit empty line before existing footers

"commit -s" used to add an empty line before adding S-o-b line only when
the last line of the existing log message is not another S-o-b line, but
c1e01b0 (commit: More generous accepting of RFC-2822 footer lines.,
2009-10-28) introduced logic to omit this empty line when the message ends
with a run of "footer" lines, to cover S-o-b's friends, e.g. Acked-by.

However, the logic was overzealous and missed one corner case.  A message
that consists of a single line that begins with Token + colon, it can be
mistaken as a S-o-b's friend.  We do want an empty line in such a case.

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

t1200: prepare for merging with Fast-forward bikeshedding

A tree-wide bikeshedding to replace "fast forward" into "fast-forward" is
in 'master'.  Since we want to keep this "test modernization" series
mergeable also to the maintenance track, we would need to tweak the test
to accept both old spellings and new spellings.

Sigh...  This kind of headache is the primary reason we try not to allow
such a tree-wide bike-shedding, but the damage has already been done.

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

t1200: further modernize test script style

Instead of using bare "cmp", use "test_cmp".  Output when the test is run
with a -v option becomes easier to diagnose when something goes wrong
because on saner platforms test_cmp uses "diff -u".

There is no need to put an extra backslash to a line that ends with a '|'
(i.e. the upstream of a pipe).

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

t1200: Make documentation and test agree

There were some differences between t1200 and the gitcore-tutorial. Add
missing tests for manually merging two branches, and use the same
commands in both files.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1200: cleanup and modernize test style

Many parts of the tests in t1200 are run outside the test harness,
circumventing the usefulness of -v and spewing messages to stdout when
-v isn't used. Fix these problems by modernizing the test a bit.

An extra test_done has existed since commit 6a74642 (git-commit --amend:
two fixes., 2006-04-20) leading to the last 6 tests never being run.
Remove it and teach the resolve merge test about fast-forward merges.
Also fix the last test's incorrect find command and prune before
checking for unpacked objects so we remove the unreachable conflict-marked
blob.

Finally, we remove the TODO notes, because fetch, push, and clone have
their own tests since t1200 was introduced and we're not going to add
them here 4 years later.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix blob linenr links in pathinfo mode

In pathinfo mode, we use <base href> that refers to the base location
of gitweb in order for various external media links to work well.
However, this means that for the page to refer to itself, it must
regenerate full link, and this is exactly what the blob view page
did not do for line numbers.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects: move thread autodetection closer to relevant code

Let's keep thread stuff close together if possible.  And in this case,
this even reduces the #ifdef noise, and allows for skipping the
autodetection altogether if delta search is not needed (like with a pure
clone).

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-backend: Test configuration options

Test the major configuration settings which control access to
the repository:

  http.getanyfile
  http.uploadpack
  http.receivepack

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-backend: Use http.getanyfile to disable dumb HTTP serving

Some repository owners may wish to enable smart HTTP, but disallow
dumb content serving.  Disallowing dumb serving might be because
the owners want to rely upon reachability to control which objects
clients may access from the repository, or they just want to
encourage clients to use the more bandwidth efficient transport.

If http.getanyfile is set to false the backend CGI will return with
'403 Forbidden' when an object file is accessed by a dumb client.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test smart http fetch and push

The top level directory "/smart/" of the test Apache server is mapped
through our git-http-backend CGI, but uses the same underlying
repository space as the server's document root.  This is the most
simple installation possible.

Server logs are checked to verify the client has accessed only the
smart URLs during the test.  During fetch testing the headers are
also logged from libcurl to ensure we are making a reasonably sane
HTTP request, and getting back reasonably sane response headers
from the CGI.

When validating the request headers used during smart fetch we munge
away the actual Content-Length and replace it with the placeholder
"xxx".  This avoids unnecessary varability in the test caused by
an unrelated change in the requested capabilities in the first want
line of the request.  However, we still want to look for and verify
that Content-Length was used, because smaller payloads should be
using Content-Length and not "Transfer-Encoding: chunked".

When validating the server response headers we must discard both
Content-Length and Transfer-Encoding, as Apache2 can use either
format to return our response.

During development of this test I observed Apache returning both
forms, depending on when the processes got CPU time.  If our CGI
returned the pack data quickly, Apache just buffered the whole
thing and returned a Content-Length.  If our CGI took just a bit
too long to complete, Apache flushed its buffer and instead used
"Transfer-Encoding: chunked".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http tests: use /dumb/ URL prefix

To clarify what part of the HTTP transprot is being tested we change
the URLs used by existing tests to include /dumb/ at the start,
indicating they use the non-Git aware code paths.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

set httpd port before sourcing lib-httpd

If LIB_HTTPD_PORT is not set already, lib-httpd will set it to the
default 8111.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5540-http-push: remove redundant fetches

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Smart HTTP fetch: gzip requests

The upload-pack requests are mostly plain text and they compress
rather well.  Deflating them with Content-Encoding: gzip can easily
drop the size of the request by 50%, reducing the amount of data
to transfer as we negotiate the common commits.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Smart fetch over HTTP: client side

The git-remote-curl backend detects if the remote server supports
the git-upload-pack service, and if so, runs git-fetch-pack locally
in a pipe to generate the want/have commands.

The advertisements from the server that were obtained during the
discovery are passed into git-fetch-pack before the POST request
starts, permitting server capability discovery and enablement.

Common objects that are discovered are appended onto the request as
have lines and are sent again on the next request.  This allows the
remote side to reinitialize its in-memory list of common objects
during the next request.

Because all requests are relatively short, below git-remote-curl's
1 MiB buffer limit, requests will use the standard Content-Length
header and be valid HTTP/1.0 POST requests.  This makes the fetch
client more tolerant of proxy servers which don't support HTTP/1.1
or the chunked transfer encoding.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Smart push over HTTP: client side

The git-remote-curl backend detects if the remote server supports
the git-receive-pack service, and if so, runs git-send-pack in a
pipe to dump the command and pack data as a single POST request.

The advertisements from the server that were obtained during the
discovery are passed into git-send-pack before the POST request
starts.  This permits git-send-pack to operate largely unmodified.

For smaller packs (those under 1 MiB) a HTTP/1.0 POST with a
Content-Length is used, permitting interaction with any server.
The 1 MiB limit is arbitrary, but is sufficent to fit most deltas
created by human authors against text sources with the occasional
small binary file (e.g. few KiB icon image).  The configuration
option http.postBuffer can be used to increase (or shink) this
buffer if the default is not sufficient.

For larger packs which cannot be spooled entirely into the helper's
memory space (due to http.postBuffer being too small), the POST
request requires HTTP/1.1 and sets "Transfer-Encoding: chunked".
This permits the client to upload an unknown amount of data in one
HTTP transaction without needing to pregenerate the entire pack
file locally.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>