mergetool: support --tool-help option like difftool does

This way we do not have to risk the list of tools going out of sync
between the implementation and the documentation.

In the same spirit as bf73fc2 (difftool: print list of valid tools
with '--tool-help', 2012-03-29), trim the list of merge backends in
the documentation.  We do not want to have a complete list of valid
tools; we only want a list to help people guess what kind of things
the tools do to be specified there, and refer them to --tool-help
for a complete list.

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

commit: check committer identity more strictly

The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about salvaging the work from .git/COMMIT_EDITMSG.

The early check for committer ident does not use the
IDENT_STRICT flag, meaning that it would not find an empty
name field. The motivation was presumably because we did not
want to be too restrictive, as later calls might be more lax
(for example, when we create the reflog entry, we do not
care too much about a real name). However, because
commit_tree will always get a strict identity to put in the
commit object itself, there is no point in being lax only to
die later (and in fact it is harmful, because the user will
have wasted time typing their commit message).

Incidentally, this bug was masked prior to 060d4bb, as the
initial loose call would taint the later strict call. So the
commit would succeed (albeit with a bogus committer line in
the commit object), and nobody noticed that our early check
did not match the later one.

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

advice: pass varargs to strbuf_vaddf, not strbuf_addf

The advise() function takes a variable number of arguments
and converts them into a va_list object to pass to strbuf
for handling. However, we accidentally called strbuf_addf
(that takes a variable number of arguments) instead of
strbuf_vaddf (that takes a va_list).

This bug dates back to v1.7.8.1-1-g23cb5bf, but we never
noticed because none of the current callers passes a string
with a format specifier in it. And the compiler did not
notice because the format string is not available at
compile time.

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

Makefile: BLK_SHA1 does not require fast htonl() and unaligned loads

block-sha1/ is fast on most known platforms.  Clarify the Makefile to
be less misleading about that.

Early versions of block-sha1/ explicitly relied on fast htonl() and
fast 32-bit loads with arbitrary alignment.  Now it uses those on some
arches but the default behavior is byte-at-a-time access for the sake
of arches like ARM, Alpha, and their kin and it is still pretty fast
on these arches (fast enough to supersede the mozilla SHA1
implementation and the hand-written ARM assembler implementation that
were bundled before).

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

Makefile: fix location of listing produced by "make subdir/foo.s"

When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without
specifying where it should put its output and the output ends up in
./sha1.s.  Confusing.

Add an -o option to the .s rule to fix this.  We were already doing
that for most compiler invocations but had forgotten it for the
assembler listings.

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

block-sha1: put expanded macro parameters in parentheses

't' is currently always a numeric constant, but it can't hurt to
prepare for the day that it becomes useful for a caller to pass in a
more complex expression.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

block-sha1: avoid pointer conversion that violates alignment constraints

With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
access 32-bit chunks of memory one byte at a time on arches that
prefer that:

#define get_be32(p)    ( \
(*((unsigned char *)(p) + 0) << 24) | \
(*((unsigned char *)(p) + 1) << 16) | \
(*((unsigned char *)(p) + 2) <<  8) | \
(*((unsigned char *)(p) + 3) <<  0) )

The code previously accessed these values by just using htonl(*p).

Unfortunately, Michael noticed on an Alpha machine that git was using
plain 32-bit reads anyway.  As soon as we convert a pointer to int *,
the compiler can assume that the object pointed to is correctly
aligned as an int (C99 section 6.3.2.3 "pointer conversions"
paragraph 7), and gcc takes full advantage by using a single 32-bit
load, resulting in a whole bunch of unaligned access traps.

So we need to obey the alignment constraints even when only dealing
with pointers instead of actual values.  Do so by changing the type
of 'data' to void *.  This patch renames 'data' to 'block' at the same
time to make sure all references are updated to reflect the new type.

Reported-tested-and-explained-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.11.3

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

Merge branch 'jk/push-delete-ref-error-message' into maint

The error message from "git push $there :bogo" (and its equivalent
"git push $there --delete bogo") mentioned that we tried and failed
to guess what ref is being deleted based on the LHS of the refspec,
which we don't.

* jk/push-delete-ref-error-message:
  push: don't guess at qualifying remote refs on deletion

Merge branch 'ar/clone-honor-umask-at-top' into maint

A handful of files and directories we create had tighter than
necessary permission bits when the user wanted to have group
writability (e.g. by setting "umask 002").

* ar/clone-honor-umask-at-top:
  add: create ADD_EDIT.patch with mode 0666
  rerere: make rr-cache fanout directory honor umask
  Restore umasks influence on the permissions of work tree created by clone

Merge branch 'cw/amend-commit-without-message' into maint

"commit --amend" used to refuse amending a commit with an empty log
message, with or without "--allow-empty-message".

* cw/amend-commit-without-message:
  Allow edit of empty message with commit --amend

Merge branch 'jk/maint-commit-amend-only-no-paths' into maint

"git commit --amend --only --" was meant to allow "Clever" people to
rewrite the commit message without making any change even when they
have already changes for the next commit added to their index, but
it never worked as advertised since it was introduced in 1.3.0 era.

* jk/maint-commit-amend-only-no-paths:
  commit: fix "--amend --only" with no pathspec

Merge branch 'tg/maint-cache-name-compare' into maint

Even though the index can record pathnames longer than 1<<12 bytes,
in some places we were not comparing them in full, potentially
replacing index entries instead of adding.

* tg/maint-cache-name-compare:
  cache_name_compare(): do not truncate while comparing paths

Merge branch 'tr/maint-show-walk' into maint

"git show"'s auto-walking behaviour was an unreliable and
unpredictable hack; it now behaves just like "git log" does when it
walks.

* tr/maint-show-walk:
  show: fix "range implies walking"
  Demonstrate git-show is broken with ranges

Merge branch 'jc/refactor-diff-stdin' into maint

"git diff", "git status" and anything that internally uses the
comparison machinery was utterly broken when the difference
involved a file with "-" as its name.  This was due to the way "git
diff --no-index" was incorrectly bolted on to the system, making
any comparison that involves a file "-" at the root level
incorrectly read from the standard input.

* jc/refactor-diff-stdin:
  diff-index.c: "git diff" has no need to read blob from the standard input
  diff-index.c: unify handling of command line paths
  diff-index.c: do not pretend paths are pathspecs

Merge branch 'mz/empty-rebase-test' into maint

We did not have test to make sure "git rebase" without extra options
filters out an empty commit in the original history.

* mz/empty-rebase-test:
  add test case for rebase of empty commit

Merge branch 'js/fast-export-paths-with-spaces' into maint

"git fast-export" produced an input stream for fast-import without
properly quoting pathnames when they contain SPs in them.

* js/fast-export-paths-with-spaces:
  fast-export: quote paths with spaces

Merge branch 'cw/no-detaching-an-unborn' into maint

"git checkout --detach", when you are still on an unborn branch,
should be forbidden, but it wasn't.

* cw/no-detaching-an-unborn:
  git-checkout: disallow --detach on unborn branch

Merge branch 'vr/use-our-perl-in-tests' into maint

Some implementations of Perl terminates "lines" with CRLF even when
the script is operating on just a sequence of bytes.  Make sure to
use "$PERL_PATH", the version of Perl the user told Git to use, in
our tests to avoid unnecessary breakages in tests.

* vr/use-our-perl-in-tests:
  t/README: add a bit more Don'ts
  tests: enclose $PERL_PATH in double quotes
  t/test-lib.sh: export PERL_PATH for use in scripts
  t: Replace 'perl' by $PERL_PATH

diff: test precedence of external diff drivers

There are three ways to specify an external diff command:
GIT_EXTERNAL_DIFF in the environment, diff.external in the
config, or a "diff" gitattribute. The current order of
precedence is:

  1. gitattribute

  2. GIT_EXTERNAL_DIFF

  3. diff.external

Usually our rule is that environment variables should take
precedence over on-disk config (i.e., option 2 should come
before option 1). However, this situation is trickier than
some, because option 1 is more specific to the individual
file than option 2 (which affects all files), so it might be
preferable. So the current behavior can be seen as
implementing "do the specific thing if we can, but fall back
to this general thing".

This is probably not what we would do if we were writing git
from scratch, but it has been this way for several years,
and is not worth changing. So let's at least document that
this is the way it's supposed to work with a test.

While we're there, let's also make sure that diff.external
(which was not previously tested at all) works by running it
through the same tests as GIT_EXTERNAL_DIFF.

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

diff: correctly disable external_diff with --no-ext-diff

Upon seeing a type-change filepair, "diff --no-ext-diff" does not
show the usual "deletion followed by addition" split patch and does
not run the external diff driver either.

This is because the logic to disable external diff was placed at a
wrong level in the callchain.  run_diff_cmd() decides to show the
split patch only when external diff driver is not configured or
specified via GIT_EXTERNAL_DIFF environment, but this is done before
checking if --no-ext-diff was given.  To make things worse,
run_diff_cmd() checks --no-ext-diff and disables the output for such
a filepair completely, as the callchain below it (e.g. builtin_diff)
does not want to handle typechange filepairs.

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

Revert "git-commit-tree(1): update synopsis"

This reverts commit d28436736a078a429213003a9472e8caeb86c286, which
was done without realizing that the updated command line argument
order was lost by mistake.

Merge branch 'kk/maint-1.7.9-commit-tree' into kk/maint-commit-tree

* kk/maint-1.7.9-commit-tree:
  commit-tree: resurrect command line parsing updates

commit-tree: resurrect command line parsing updates

79a9312 (commit-tree: update the command line parsing, 2011-11-09)
updated the command line parser to understand the usual "flags first
and then non-flag arguments" order, in addition to the original and
a bit unusual "tree comes first and then zero or more -p <parent>".

Unfortunately, ba3c69a (commit: teach --gpg-sign option, 2011-10-05)
broke it by mistake.  Resurrect it, and protect the feature with a
test from future breakages.

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

Documentation/git-daemon: add missing word

Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am: indicate where a failed patch is to be found

If "git am" fails to apply something, the end user may need to know
where to find the patch that failed to apply, so that the user can
do other things (e.g. trying "GNU patch" on it, running "diffstat"
to see what it tried to change, etc.)  The input to "am" may have
contained more than one patch, or the message may have been MIME
encoded, and knowing what the user fed to "am" does not help very
much for this purpose.

Also introduce advice.amworkdir configuration to allow people who
learned where to look to squelch this message.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7003: add test to filter a branch with a commit at epoch

Running filter-branch on a history that has a commit with timestamp
at epoch used to fail, but it should have been fixed.  Add test to
make sure it won't break again.

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

date.c: Fix off by one error in object-header date parsing

It is perfectly OK for a valid decimal integer to begin with '9' but
116eb3a (parse_date(): allow ancient git-timestamp, 2012-02-02) did
not express the range correctly.

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

submodules: don't stumble over symbolic links when cloning recursively

Since 69c3051 (submodules: refactor computation of relative gitdir path)
cloning a submodule recursively fails for nested submodules when a
symbolic link is part of the path to the work tree of the superproject.

This happens when module_clone() tries to find the relative paths between
the work tree and the git dir. When a symbolic link in current $PWD points
to a directory that is at a different level, then determining the number
of "../" needed to traverse to the superproject's work tree leads to a
wrong result.

As there is no portable way to say "pwd -P", use cd_to_toplevel to remove
the link from $PWD, which fixes this problem.

A test for this issue has been added to t7406.

Reported-by: Bob Halley <halley@play-bow.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.11.2

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

Merge branch 'jc/maint-blame-unique-abbrev' into maint

"git blame" did not try to make sure that the abbreviated commit
object names in its output are unique.

* jc/maint-blame-unique-abbrev:
  blame: compute abbreviation width that ensures uniqueness

Merge branch 'rj/platform-pread-may-be-thread-unsafe' into maint

On Cygwin, the platform pread(2) is not thread safe, just like our own
compat/ emulation, and cannot be used in the index-pack program.
Makefile variable NO_THREAD_SAFE_PREAD can be defined to avoid use of
this function in a threaded program.

* rj/platform-pread-may-be-thread-unsafe:
  index-pack: Disable threading on cygwin

Merge branch 'th/diff-no-index-fixes' into maint

"git diff --no-index" did not correctly handle relative paths and
did not correctly give exit codes when run under "--quiet" option.

* th/diff-no-index-fixes:
  diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes
  diff: handle relative paths in no-index

Merge branch 'nd/clone-single-fix' into maint

"git clone --single-branch" to clone a single branch did not limit
the cloning to the specified branch.

* nd/clone-single-fix:
  clone: fix ref selection in --single-branch --branch=xxx

Merge branch 'jc/rev-list-simplify-merges-first-parent' into maint

When "git log" gets "--simplify-merges/by-decoration" together with
"--first-parent", the combination of these options makes the
simplification logic to use in-core commit objects that haven't been
examined for relevance, either producing incorrect result or taking
too long to produce any output.  Teach the simplification logic to
ignore commits that the first-parent traversal logic ignored when
both are in effect to work around the issue.

* jc/rev-list-simplify-merges-first-parent:
  revision: ignore side parents while running simplify-merges
  revision: note the lack of free() in simplify_merges()
  revision: "simplify" options imply topo-order sort

Merge branch 'hv/submodule-update-nuke-submodules' into maint

"git add" allows adding a regular file to the path where a submodule
used to exist, but "git update-index" did not allow an equivalent
operation to Porcelain writers.

* hv/submodule-update-nuke-submodules:
  update-index: allow overwriting existing submodule index entries

Merge branch 'jk/diff-no-index-pager' into maint

"git diff --no-index" did not work with pagers correctly.

* jk/diff-no-index-pager:
  do not run pager with diff --no-index --quiet
  fix pager.diff with diff --no-index

Merge branch 'mm/verify-filename-fix' into maint

"git diff COPYING HEAD:COPYING" gave a nonsense error message that
claimed that the treeish HEAD did not have COPYING in it.

* mm/verify-filename-fix:
  verify_filename(): ask the caller to chose the kind of diagnosis
  sha1_name: do not trigger detailed diagnosis for file arguments

Merge branch 'cn/cherry-pick-range-docs' into maint

The documentation for "git cherry-pick A B..C" was misleading.

* cn/cherry-pick-range-docs:
  git-cherry-pick.txt: clarify the use of revision range notation
  Documentation: --no-walk is no-op if range is specified

Merge branch 'jc/ustar-checksum-is-unsigned' into maint

"git archive" incorrectly computed the header checksum; the symptom
was observed only when using pathnames with hi-bit set.

* jc/ustar-checksum-is-unsigned:
  archive: ustar header checksum is computed unsigned

Merge branch 'jc/bundle-complete-notice' into maint

Running "git bundle verify" on a bundle that records a complete
history said "it requires these 0 commits".

* jc/bundle-complete-notice:
  tweak "bundle verify" of a complete history

Merge branch 'jc/ls-files-i-dir' into maint

"git ls-files --exclude=t -i" did not consider anything under t/ as
excluded, as it did not pay attention to exclusion of leading paths
while walking the index.  Other two users of excluded() are also
updated.

* jc/ls-files-i-dir:
  dir.c: make excluded() file scope static
  unpack-trees.c: use path_excluded() in check_ok_to_remove()
  builtin/add.c: use path_excluded()
  path_excluded(): update API to less cache-entry centric
  ls-files -i: micro-optimize path_excluded()
  ls-files -i: pay attention to exclusion of leading paths

Merge branch 'jc/request-pull-match-tagname' into maint

"git request-pull $url dev" when the tip of "dev" branch was tagged
with "ext4-for-linus" used the contents from the tag in the output
but still asked the "dev" branch to be pulled, not the tag.

* jc/request-pull-match-tagname:
  request-pull: really favor a matching tag

cache_name_compare(): do not truncate while comparing paths

We failed to use ce_namelen() equivalent and instead only compared
up to the CE_NAMEMASK bytes by mistake.  Adding an overlong path
that shares the same common prefix as an existing entry in the index
did not add a new entry, but instead replaced the existing one, as
the result.

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

commit: fix "--amend --only" with no pathspec

When we do not have any pathspec, we typically disallow an
explicit "--only", because it makes no sense (your commit
would, by definition, be empty). But since 6a74642
(git-commit --amend: two fixes., 2006-04-20), we have
allowed "--amend --only" with the intent that it would amend
the commit, ignoring any contents staged in the index.

However, while that commit allowed the combination, we never
actually implemented the logic to make it work. The current
code notices that we have no pathspec and assumes we want to
do an as-is commit (i.e., the "--only" is ignored).

Instead, we must make sure to follow the partial-commit
code-path. We also need to tweak the list_paths function to
handle a NULL pathspec.

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

add: create ADD_EDIT.patch with mode 0666

We should be letting the user's umask take care of
restricting permissions. Even though this is a temporary
file and probably nobody would notice, this brings us in
line with other temporary file creations in git (e.g.,
choosing "e"dit from git-add--interactive).

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

filter-branch: do not forget the '@' prefix to force git-timestamp

For some reason, this script reinvents, instead of refactoring the
existing one in git-sh-setup, the logic to grab ident information
from an existing commit; it was missed when the corresponding logic
in git-sh-setup was updated with 2c733fb (parse_date(): '@' prefix
forces git-timestamp, 2012-02-02).

Teach the script that it is OK to have a way ancient timestamp in
the commits that are being filtered.

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

rerere: make rr-cache fanout directory honor umask

This is the last remaining call to mkdir(2) that restricts the permission
bits by passing 0755.  Just use the same mkdir_in_gitdir() used to create
the leaf directories.

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

Restore umasks influence on the permissions of work tree created by clone

The original version of the git-clone just used mkdir(1) to create
the working directories.  The version rewritten in C creates all
directories inside the working tree by using the mode argument of
0777 when calling mkdir(2) to let the umask take effect.

But the top-level directory of the working tree is created by
passing the mode argument of 0755 to mkdir(2), which results in an
overly tight restriction if the user wants to make directories group
writable with a looser umask like 002.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Allow edit of empty message with commit --amend

"git commit --amend" used on a commit with an empty message fails
unless -m is given, whether or not --allow-empty-message is
specified.

Allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later
if an empty message is saved from the editor (this check was
already necessary to prevent a non-empty commit message being edited
to an empty one).

Add a test for --amend --edit of an empty commit message which fails
without this fix, as it's a rare case that won't get frequently
tested otherwise.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make <refname> documentation more consistent.

Formerly, the documentation for <refname> would occasionally say
<name> instead of <refname>. Now it uniformly uses <refname>.

Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: don't guess at qualifying remote refs on deletion

When we try to push a ref and the right-hand side of the
refspec does not find a match, we try to create it. If it is
not fully qualified, we try to guess where it would go in
the refs hierarchy based on the left-hand source side. If
the source side is not a ref, then we give up and give a
long explanatory message.

For deletions, however, this doesn't make any sense. We
would never want to create on the remote side, and if an
unqualified ref can't be matched, it is simply an error. The
current code handles this already because the left-hand side
is empty, and therefore does not give us a hint as to where
the right-hand side should go, and we properly error out.
Unfortunately, the error message is the long "we tried to
qualify this, but the source side didn't let us guess"
message, which is quite confusing.

Instead, we can just be more succinct and say "we can't
delete this because we couldn't find it". So before:

  $ git push origin :bogus
  error: unable to push to unqualified destination: bogus
  The destination refspec neither matches an existing ref on the remote nor
  begins with refs/, and we are unable to guess a prefix based on the source ref.
  error: failed to push some refs to '$URL'

and now:

  $ git push origin :bogus
  error: unable to delete 'bogus': remote ref does not exist
  error: failed to push some refs to '$URL'

It is tempting to also catch a fully-qualified ref like
"refs/heads/bogus" and generate the same error message.
However, that currently does not error out at all, and
instead gets sent to the remote side, which typically
generates a warning:

  $ git push origin:refs/heads/bogus
  remote: warning: Deleting a non-existent ref.
  To $URL
   - [deleted]         bogus

While it would be nice to catch this error early, a
client-side error would mean aborting the push entirely and
changing push's exit code. For example, right now you can
do:

  $ git push origin refs/heads/foo refs/heads/bar

and end up in a state where "foo" and "bar" are deleted,
whether both of them currently exist or not (and see an
error only if we actually failed to contact the server).
Generating an error would cause a regression for this use
case.

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

Merge branch 'maint' of git://github.com/git-l10n/git-po into maint

Update Swedish translation (1066t0f0u)

blame: compute abbreviation width that ensures uniqueness

Julia Lawall noticed that in linux-next repository the commit object
60d5c9f5 (shown with the default abbreviation width baked into "git
blame") in output from

  $ git blame -L 3675,3675 60d5c9f5b -- \
      drivers/staging/brcm80211/brcmfmac/wl_iw.c

is no longer unique in the repository, which results in "short SHA1
60d5c9f5 is ambiguous".

Compute the minimum abbreviation width that ensures uniqueness when
the user did not specify the --abbrev option to avoid this.

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

Update Swedish translation (1066t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

diff-index.c: "git diff" has no need to read blob from the standard input

Only "diff --no-index -" does.  Bolting the logic into the low-level
function diff_populate_filespec() was a layering violation from day
one.  Move populate_from_stdin() function out of the generic diff.c
to its only user, diff-index.c.

Also make sure "-" from the command line stays a special token "read
from the standard input", even if we later decide to sanitize the
result from prefix_filename() function in a few obvious ways,
e.g. removing unnecessary "./" prefix, duplicated slashes "//" in
the middle, etc.

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

diff-index.c: unify handling of command line paths

Regardless of where in the directory hierarchy you are, "-" on the
command line means the standard input.  The old code knew too much
about how the low level machinery uses paths to read from the
working tree and did not bother to have the same check for "-" when
the command is run from the top-level.

Unify the codepaths for subdirectory case and toplevel case into one
and make it clearer.

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

diff-index.c: do not pretend paths are pathspecs

"git diff --no-index" takes exactly two paths, not pathspecs, and
has its own way queue_diff() to populate the diff_queue.  Do not
call diff_tree_setup_paths(), pretending as it takes pathspecs.

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

fast-export: quote paths with spaces

A path containing a space must be quoted when used as an
argument to either the copy or rename commands (because
unlike other commands, the path is not the final thing on
the line for those commands).

Commit 6280dfdc3b (fast-export: quote paths in output,
2011-08-05) previously attempted to fix fast-export's
quoting by passing all paths through quote_c_style().
However, that function does not consider the space to be a
character which requires quoting, so let's special-case the
space inside print_path(). This will cause space-containing
paths to also be quoted in other commands where such quoting
is not strictly necessary, but it does not hurt to do so.

The test from 6280dfdc3b did not detect this because, while
it does introduce renames in the export stream, it does not
actually turn on rename detection, so they were presented as
pairs of deletions/adds. Using "-M" reveals the bug.

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

add test case for rebase of empty commit

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

index-pack: Disable threading on cygwin

The Cygwin implementation of pread() is not thread-safe since, just
like the emulation provided by compat/pread.c, it uses a sequence of
seek-read-seek calls. In order to avoid failues due to thread-safety
issues, commit b038a61 disables threading when NO_PREAD is defined.
(ie when using the emulation code in compat/pread.c).

We introduce a new build variable, NO_THREAD_SAFE_PREAD, which allows
use to disable the threaded index-pack code on cygwin, in addition to
the above NO_PREAD case.

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

git-checkout: disallow --detach on unborn branch

abe199808c (git checkout -b: allow switching out of an unborn branch)
introduced a bug demonstrated by

  git checkout --orphan foo
  git checkout --detach
  git symbolic-ref HEAD

which gives 'refs/heads/(null)'.

This happens because we strbuf_addf(&branch_ref, "refs/heads/%s",
opts->new_branch) when opts->new_branch can be NULL for --detach.

Catch and forbid this case, adding a test to t2017 to catch it in
future.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-submodule.sh: fix filename in comment.

Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add--interactive.perl: Remove two unused variables

The patch 8f0bef6 refactored this script and made the variable $fh
unneeded in subs diff_applies and patch_update_file, but forgot to
remove them.

Signed-off-by: Thomas Badie <badie@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: add a bit more Don'ts

Add a few more advices that we often have to give to new test
writers.

Also update an example where a double quote pair is used to enclose
a test body to use a single quote pair, which is more readable and
more importantly gives saner semantics for variable substitution.

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

tests: enclose $PERL_PATH in double quotes

Otherwise it will be split at a space after "Program" when it is set
to "\\Program Files\perl" or something silly like that.

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

t/test-lib.sh: export PERL_PATH for use in scripts

Most notably, t4031 creates a small shell script that invokes perl
and we want to use "$PERL_PATH" to name the version of Perl suitable
for our use, read from GIT-BUILD-OPTS.  The test would fail when it
is directly run in t/ directory from the shell or "make" is run in t/
directory.

This problem was hidden from "make test" run in the top-level
directory, because its Makefile exports PERL_PATH.

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

Documentation: Fix misspellings

Signed-off-by: Leila Muhtasib <muhtasib@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: fix ref selection in --single-branch --branch=xxx

 - do not fetch HEAD
 - do not also fetch refs following "xxx"

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes

When running 'git diff --quiet <file1> <file2>', if file1 or file2
is outside the repository, it will exit(0) even if the files differ.
It should exit(1) when they differ.

This happens because 'diff_no_index' looks at the 'found_changes'
member from 'diff_options' to determine if changes were made.  This
is the wrong thing to do, since it is only set if xdiff is actually
run and it finds a change (the diff machinery will optimize out the
xdiff call when it is not necessary) and in that case HAS_CHANGED
flag needs to be taken into account.

Use diff_result_code() that knows all these details for the correct
exit value instead.

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

diff: handle relative paths in no-index

When diff-no-index is given a relative path to a file outside the
repository, it aborts with error. However, if the file is given
using an absolute path, the diff runs as expected. The two cases
should be treated the same.

Tests and commit message by Tim Henigan.

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

Git 1.7.11.1

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

docs: always define git-relative-html-prefix attribute

Commit fe77b41 introduced a new attribute to let the linkgit macro
create cross-directory HTML references from the technical/ and howto/
subdirectories back to the main documentation. We define that attribute
to "../" on the command-line when building inside those subdirectories,
and otherwise leave it unset under the assumption that it would default
to being blank.  Instead, asciidoc omits the link entirely, leading to
broken documentation. Fix this by defining git-relative-html-prefix to
blank in asciidoc.conf (and an instance on the command-line, when
present, will override it).

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

show: fix "range implies walking"

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

Demonstrate git-show is broken with ranges

The logic of git-show has remained largely unchanged since around
5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start
a revision walker with no_walk=1, look at its pending objects and
handle them one-by-one.  For commits, this means stuffing them into a
new queue all alone, and running the walker.

Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came
along and set no_walk=0 whenever the user specifies a range.  Which
appears to work fine, until you actually prod it hard enough, as the
preceding commit shows: UNINTERESTING commits will be marked as such,
but not walked further to propagate the marks.

Demonstrate this with the main tests of this patch: 'showing a range
walks (Y shape)'.  The Y shape of history ensures that propagating the
UNINTERESTING marks is necessary to correctly exclude the main1
commit.  The only example I could find actually requires that the
negative revisions are listed later, and in this scenario a dotted
range actually works.  However, it is easy to find examples in git.git
where a dotted range is wrong, e.g.

  $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l
  1297
  $ git rev-list v1.7.0..v1.7.1 | wc -l
  702

While there, also test a few other things that are not covered so far:
the -N way of triggering a range (added in 5853cae, DWIM 'git show -5'
to 'git show --do-walk -5', 2010-06-01), and the interactions of tags,
commits and ranges.

Pointed out by Dr_Memory on #git.

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

git-commit-tree(1): update synopsis

Even with many new kinds of options, the command still takes the
single <tree> as the first argument.

Probably we would want to update the command to allow it to take
<tree>-ish at the end for consistency.

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

Documentation: spelling fixes

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

verify_filename(): ask the caller to chose the kind of diagnosis

verify_filename() can be called in two different contexts. Either we
just tried to interpret a string as an object name, and it fails, so
we try looking for a working tree file (i.e. we finished looking at
revs that come earlier on the command line, and the next argument
must be a pathname), or we _know_ that we are looking for a
pathname, and shouldn't even try interpreting the string as an
object name.

For example, with this change, we get:

  $ git log COPYING HEAD:inexistant
  fatal: HEAD:inexistant: no such path in the working tree.
  Use '-- <path>...' to specify paths that do not exist locally.
  $ git log HEAD:inexistant
  fatal: Path 'inexistant' does not exist in 'HEAD'

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_name: do not trigger detailed diagnosis for file arguments

diagnose_invalid_sha1_path() is meant to be called to diagnose a
misspelt <treeish>:<pathname> when <pathname> does not exist in
<treeish>.  However, the code may call it if <treeish>:<pathname> is
invalid (which triggers another call with only_to_die == 1), but for
another reason. This happens when calling e.g.

  git log existing-file HEAD:existing-file

because existing-file is a path and not a revision, the code
verifies that the arguments that follow to be paths.  This leads to
an incorrect message like "existing-file does not exist in HEAD",
even though the path exists in HEAD.

Check that the search for <pathname> in <treeish> fails before
triggering the diagnosis.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.11

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

Sync with 1.7.10.5

Git 1.7.10.5

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

Do not autosquash in case of an implied interactive rebase

The option to autosquash is only used in case of an interactive rebase.
When merges are preserved, rebase uses an interactive rebase internally,
but in this case autosquash should still be disabled.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/maint-fast-export-mark-error' into maint

"git fast-export" did not give a readable error message when the same
mark erroneously appeared twice in the --import-marks input.

Merge git://github.com/git-l10n/git-po

Updated Italian translations.

* git://github.com/git-l10n/git-po:
  l10n: it.po: translate 212 new messages

Merge branch 'as/diff-shortstat-ignore-binary'

# By Alexander Strasser
* as/diff-shortstat-ignore-binary:
  diff: Only count lines in show_shortstats

diff: Only count lines in show_shortstats

Do not mix byte and line counts. Binary files have byte counts;
skip them when accumulating line insertions/deletions.

The regression was introduced in e18872b.

Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

do not run pager with diff --no-index --quiet

There is no point in running a pager when --quiet is given,
since we are producing no output. The regular diff code path
handles this already, because --quiet implies --exit-code,
and we check for --exit-code when deciding not to run the
pager.

However, the "quiet implies exit-code" logic is done in
diff_setup_done, and the no-index code path sets up its
pager before running diff_setup_done, and misses this case.

We can fix this by reordering our initialization.
Currently we do:

  1. read command line arguments into diff_options

  2. Set pager if EXIT_CODE not requested

  3. always set EXIT_CODE, since we are emulating
     traditional diff

  4. call diff_setup_done

We can fix the problem by moving pager initialization (step
2) after step 4. But step 3 must come after step 2 (since we
want to know whether the _user_ requested --exit-code, not
whether we turned it on unconditionally). So we must move
both.

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

fix pager.diff with diff --no-index

git-diff does not rely on the git wrapper to setup its
pager; instead, it sets it up on its own after seeing
whether --quiet or --exit-code has been specified.  After
diff_no_index was split off from cmd_diff, commit b3fde6c
(git diff --no-index: default to page like other diff
frontends, 2008-05-26) duplicated the one-liner from
cmd_diff to turn on the pager.

Later, commit 8f0359f (Allow pager of diff command be
enabled/disabled, 2008-07-21) taught the the version in
cmd_diff to respect the pager.diff config, but the version
in diff_no_index was left behind. This meant that

  git -c pager.diff=0 diff a b

would not use a pager, but

  git -c pager.diff=0 diff --no-index a b

would.  Let's fix it by factoring out a common function.

While we're there, let's update the antiquated comment,
which claims that the pager interferes with propagating the
exit code; this has not been the case since ea27a18 (spawn
pager via run_command interface, 2008-07-22).

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

perl/Makefile: install Git::SVN::* when NO_PERL_MAKEMAKER=yes, too

v1.7.11-rc1~12^2~2 (2012-05-27) and friends split some git-svn code
into separate modules but did not update the fallback rules to install
them when NO_PERL_MAKEMAKER is set.  Add the appropriate rules so
users without MakeMaker can use git-svn again.

Affected modules: Git::SVN::Prompt, Git::SVN::Fetcher,
Git::SVN::Editor, Git::SVN::Ra, Git::SVN::Memoize::YAML.

Reported-by: Adam Roben <adam@roben.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmali.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perl/Makefile.PL: warn about duplicate module list in perl/Makefile

Adding or removing a module requires modifying both files to support
builds with and without MakeMaker.  Add a comment to remind patch
authors and reviewers at the crucial moment.

Longer term, it would be nicer to maintain a single list, perhaps in a
separate file used by both build systems.

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

builtin.h: remove unused cmd_<foo> declarations

These were left in builtin.h after they were converted into
stand-alone programs or removed after experiments finished.

Signed-off-by: Luka Perkov <lists@lukaperkov.net>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-cherry-pick.txt: clarify the use of revision range notation

When given a set of commits, cherry-pick will apply the changes for
all of them. Specifying a simple range will also work as expected.

This can lead the user to think that

    git cherry-pick A B..C

may apply A and then B..C, but that is not what happens.

Instead the revs are given to a single invocation of rev-list, which
will consider A and C as positive revs and B as a negative one.  The
commit A will not be used if it is an ancestor of B.

Add a note about this and add an example with this particular
syntax, which has shown up on the list a few times.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: --no-walk is no-op if range is specified

The existing description can be misleading and cause the reader to
think that --no-walk will do something if they specify a range in the
command line instead of a set of revs.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Do not use bare 0 to mean (point-min)

Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Use with-current-buffer where appropriate

In git-blame-filter and git-blame-create-overlay we want to save
(along with the values of point and mark) the current-buffer in scope
when calling the functions.  The idiom

    (save-excursion
      (set-buffer buf)
      ...)

will correctly restore the correct buffer, but will not save the
values of point and mark in buf (only in the buffer current when the
save-excursion call is executed).  The intention of these functions is
to save the current buffer from the calling scope and the values of
point and mark in the buffer they are modifying.  The correct idiom
for this is

    (with-current-buffer buf
      (save-excursion
        ...))

Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-blame.el: Do not use goto-line in lisp code

goto-line is a user-level command, instead use the lisp-level
construct recommended in Emacs documentation.

Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: it.po: translate 212 new messages

Signed-off-by: Marco Paolone <marcopaolone@gmail.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

revision: ignore side parents while running simplify-merges

The simplify_merges() function needs to look at all history chain to
find the closest ancestor that is relevant after the simplification,
but after --first-parent traversal, side parents haven't been marked
for relevance (they are irrelevant by definition due to the nature
of first-parent-only traversal) nor culled from the parents list of
resulting commits.

We cannot simply remove these side parents from the parents list, as
the output phase still wants to see the parents.  Instead, teach
simplify_one() and its callees to ignore the later parents.

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

git: Wrong parsing of ssh urls with IPv6 literals ignores port

If we encounter an address part shaped like "[HOST]:PORT", we skip the opening
bracket and replace the closing one with a NUL.  The variable host then points
to HOST and we've cut off the PORT part.  Thus, when we go looking for it using
host a bit later, we can't find it.  Start at end instead, which either points
to the colon, if present, or is equal to host.

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