Merge branch 'jk/maint-gitweb-test-use-sane-perl' into maint

When using a Perl script on a system where "perl" found on user's $PATH
could be ancient or otherwise broken, we allow builders to specify the
path to a good copy of Perl with $PERL_PATH.  The gitweb test forgot to
use that Perl when running its test.

By Jeff King (1) and Zbigniew Jędrzejewski-Szmek (1)
* jk/maint-gitweb-test-use-sane-perl:
  Consistently use perl from /usr/bin/ for scripts
  t/gitweb-lib: use $PERL_PATH to run gitweb

Merge branch 'js/daemon-test-race-fix' into maint

The test scaffolding for git-daemon was flaky.

By Johannes Sixt
* js/daemon-test-race-fix:
  t5570: fix forwarding of git-daemon messages via cat

Merge branch 'jk/maint-config-bogus-section' into maint

"git config --rename-section" to rename an existing section into a bogus
one did not check the new name.

By Jeff King
* jk/maint-config-bogus-section:
  config: reject bogus section names for --rename-section

Merge branch 'pw/t5800-import-race-fix' into maint

The test scaffolding for fast-import was flaky.

By Pete Wyckoff
* pw/t5800-import-race-fix:
  git-remote-testgit: fix race when spawning fast-import

Merge branch 'rt/cherry-revert-conflict-summary' into maint

In the older days, the header "Conflicts:" in "cherry-pick" and "merge"
was separated by a blank line from the list of paths that follow for
readability, but when "merge" was rewritten in C, we lost it by
mistake. Remove the newline from "cherry-pick" to make them match again.

By Ralf Thielow
* rt/cherry-revert-conflict-summary:
  sequencer: remove additional blank line

Merge branch 'cb/maint-report-mount-point-correctly-in-setup' into maint

The filesystem boundary was not correctly reported when .git directory
discovery stopped at a mount point.

By Clemens Buchacher
* cb/maint-report-mount-point-correctly-in-setup:
  properly keep track of current working directory

git p4 doc: fix formatting

Attach example sections to previous level of indenting.

Fix a trailing ::

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/merge-reduce-parents-early' into maint

Octopus merge strategy did not reduce heads that are recorded in the final
commit correctly.

By Junio C Hamano (4) and Michał Kiedrowicz (1)
* jc/merge-reduce-parents-early:
  fmt-merge-msg: discard needless merge parents
  builtin/merge.c: reduce parents early
  builtin/merge.c: collect other parents early
  builtin/merge.c: remove "remoteheads" global variable
  merge tests: octopus with redundant parents

Merge branch 'cb/cherry-pick-rev-path-confusion' into maint

The command line parser choked "git cherry-pick $name" when $name can be
both revision name and a pathname, even though $name can never be a path
in the context of the command.

By Clemens Buchacher
* cb/cherry-pick-rev-path-confusion:
  cherry-pick: do not expect file arguments

Merge branch 'cb/http-multi-curl-auth' into maint

HTTP transport that requires authentication did not work correctly when
multiple connections are used simultaneously.

By Jeff King (3) and Clemens Buchacher (1)
* cb/http-multi-curl-auth:
  http: use newer curl options for setting credentials
  http: clean up leak in init_curl_http_auth
  fix http auth with multiple curl handles
  http auth fails with multiple curl handles

Merge branch 'mb/fetch-call-a-non-branch-a-ref' into maint

The report from "git fetch" said "new branch" even for a non branch ref.

By Marc Branchaud
* mb/fetch-call-a-non-branch-a-ref:
  fetch: describe new refs based on where it came from
  fetch: Give remote_ref to update_local_ref() as well

Merge branch 'rl/maint-stash-i18n-save-error' into maint

i18n marking for an error message for "git stash --notavalidoption"
was incorrect.

By Ross Lagerwall
* rl/maint-stash-i18n-save-error:
  stash: use eval_gettextln correctly

Merge branch 'jm/maint-strncpy-diff-no-index' into maint

"diff --no-index" codepath had a few places that used fixed-size
buffer and truncated paths that are too long.

By Jim Meyering (1) and Junio C Hamano (1)
* jm/maint-strncpy-diff-no-index:
  diff --no-index: use strbuf for temporary pathnames
  diff: avoid stack-buffer-read-overrun for very long name

Git 1.7.10.1

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

Merge branch 'pw/fast-import-dataref-parsing' into maint

The parser in "fast-import" did not diagnose ":9" style references that is
not followed by required SP/LF as an error.

By Pete Wyckoff
* pw/fast-import-dataref-parsing:
  fast-import: tighten parsing of datarefs

Merge branch 'it/fetch-pack-many-refs' into maint

When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl, may
fail to hold all of them. Now such an internal invocation can feed the
references through the standard input of "fetch-pack".

By Ivan Todoroski
* it/fetch-pack-many-refs:
  remote-curl: main test case for the OS command line overflow
  fetch-pack: test cases for the new --stdin option
  remote-curl: send the refs to fetch-pack on stdin
  fetch-pack: new --stdin option to read refs from stdin

Conflicts:
t/t5500-fetch-pack.sh

Merge branch 'jl/maint-submodule-recurse-fetch' into maint

"git fetch" that recurses into submodules on demand did not check if it
needs to go into submodules when non branches (most notably, tags) are
fetched.

By Jens Lehmann
* jl/maint-submodule-recurse-fetch:
  submodules: recursive fetch also checks new tags for submodule commits

Merge branch 'jc/maint-blame-minimal' into maint

"git blame" started missing quite a few changes from the origin since we
stopped using the diff minimalization by default in v1.7.2 era.

Teach "--minimal" option to "git blame" to work around this regression.

* jc/maint-blame-minimal:
  blame: accept --need-minimal

Merge branch 'lp/maint-diff-three-dash-with-graph' into maint

"log -p --graph" used with "--stat" had a few formatting error.

By Lucian Poston
* lp/maint-diff-three-dash-with-graph:
  t4202: add test for "log --graph --stat -p" separator lines
  log --graph: fix break in graph lines
  log --graph --stat: three-dash separator should come after graph lines

Merge branch 'jk/rebase-i-submodule-conflict-only' into maint

Giving "--continue" to a conflicted "rebase -i" session skipped a
commit that only results in changes to submodules.

By John Keeping
* jk/rebase-i-submodule-conflict-only:
  rebase -i continue: don't skip commits that only change submodules

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

By Byrial Jensen (2) and others
via Jiang Xin (1) and Ralf Thielow (1)
* 'maint' of https://github.com/git-l10n/git-po:
  l10n: Initial German translation
  l10n: Update Simplified Chinese translation
  l10n: Update git.pot (2 new messages)
  l10n: Add the German translation team and initialize de.po
  l10n: Add Danish team (da) to list of teams
  l10n: New da.po file with 0 translations
  l10n: Updated pt_PT language

Consistently use perl from /usr/bin/ for scripts

While the majority of scripts use '#!/usr/bin/perl', some use
'#!/usr/bin/env perl'. In the end there is no difference, because the
Makefile rewrites "#!.*perl" with "#!$PERL_PATH" in scripted
Porcelains before installing. Nevertheless, the second form can be
misleading, because it suggests that perl found first in $PATH will be
used.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/gitweb-lib: use $PERL_PATH to run gitweb

The current code runs "perl gitweb.cgi" to test gitweb. This
will use whatever version of perl happens to be first in the
PATH. We are better off using the specific perl that the
user specified via PERL_PATH, which matches what gets put on
the #!-line of the built gitweb.cgi.

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

l10n: Initial German translation

Helped-by: Thomas Kuchs
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>

l10n: Update Simplified Chinese translation

Translate 2 new messages come from git maint branch.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: Update git.pot (2 new messages)

Changes of po/git.pot from v1.7.10 to v1.7.10-55-g868d6

 * 2 new l10n messages at lines: 1583, 2730

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge maint branch for tracking l10n updates of git stable version

Use master branch to track l10n updates for git next release, while
use maint branch to track l10n updates for git stable version.

l10n: Add the German translation team and initialize de.po

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

t5570: fix forwarding of git-daemon messages via cat

The shell function that starts git-daemon wants to read the first line of
the daemon's stderr to ensure that it started correctly. Subsequent daemon
errors should be redirected to fd 4 (which is the terminal in verbose mode
or /dev/null in quiet mode). To that end the shell script used 'read' to
get the first line of output, and then 'cat &' to forward everything else
in a background process.

The problem is, that 'cat >&4 &' does not produce any output because the
shell redirects a background process's stdin to /dev/null. To have this
command invocation do anything useful, we have to redirect its stdin
explicitly (which overrides the /dev/null redirection).

The shell function connects the daemon's stderr to its consumers via a
FIFO. We cannot just do this:

   read line <git_daemon_output
   cat <git_daemon_output >&4 &

because after the first redirection the pipe is closed and the daemon
could receive SIGPIPE if it writes at the wrong moment. Therefore, we open
the readable end of the FIFO only once on fd 7 in the shell and dup from
there to the stdin of the two consumers.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start preparing for 1.7.10.1

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

Merge branch 'jk/run-command-eacces' into maint

When PATH contains an unreadable directory, alias expansion code did
not kick in, and failed with an error that said "git-subcmd" was not
found.

By Jeff King (1) and Ramsay Jones (1)
* jk/run-command-eacces:
  run-command: treat inaccessible directories as ENOENT
  compat/mingw.[ch]: Change return type of exec functions to int

Merge branch 'jc/push-upstream-sanity' into maint

The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch is
set to push to a remote different from $there, used to push to $there
using the upstream information to a remote unreleated to $there.

* jc/push-upstream-sanity:
  push: error out when the "upstream" semantics does not make sense

Merge branch 'jc/maint-clean-nested-worktree-in-subdir' into maint

"git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the protection
applied only to such working trees that are at the top-level of the
current project by mistake.

* jc/maint-clean-nested-worktree-in-subdir:
  clean: preserve nested git worktree in subdirectories

Merge branch 'jk/diff-no-rename-empty' into maint

Rename detection logic used to match two empty files as renames during
merge-recursive, leading unnatural mismerges.

By Jeff King
* jk/diff-no-rename-empty:
  merge-recursive: don't detect renames of empty files
  teach diffcore-rename to optionally ignore empty content
  make is_empty_blob_sha1 available everywhere
  drop casts from users EMPTY_TREE_SHA1_BIN

Merge branch 'rs/combine-diff-zero-context-at-the-beginning' into maint

An age-old corner case bug in combine diff (only triggered with -U0
and the hunk at the beginning of the file needs to be shown) has been
fixed.

By René Scharfe
* rs/combine-diff-zero-context-at-the-beginning:
  combine-diff: fix loop index underflow

Merge branch 'jc/commit-unedited-template' into maint

When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty message",
which was utterly wrong.

By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
  Documentation/git-commit: rephrase the "initial-ness" of templates
  git-commit.txt: clarify -t requires editing message
  commit: rephrase the error when user did not touch templated log message
  commit: do not trigger bogus "has templated message edited" check
  t7501: test the right kind of breakage

Merge branch 'jk/add-p-skip-conflicts' into maint

"git add -p" is not designed to deal with unmerged paths but did
not exclude them and tried to apply funny patches only to fail.

By Jeff King
* jk/add-p-skip-conflicts:
  add--interactive: ignore unmerged entries in patch mode

Merge branch 'jc/commit-hook-authorship' into maint

"git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do so
when the end user overrode the authorship via the "GIT_AUTHOR_NAME"
environment variable.

* jc/commit-hook-authorship:
  commit: pass author/committer info to hooks
  t7503: does pre-commit-hook learn authorship?
  ident.c: add split_ident_line() to parse formatted ident line

Merge branch 'tr/maint-word-diff-regex-sticky' into maint

The regexp configured with diff.wordregex was incorrectly reused
across files.

By Thomas Rast (2) and Johannes Sixt (1)
* tr/maint-word-diff-regex-sticky:
  diff: tweak a _copy_ of diff_options with word-diff
  diff: refactor the word-diff setup from builtin_diff_cmd
  t4034: diff.*.wordregex should not be "sticky" in --word-diff

Merge branch 'jh/notes-merge-in-git-dir-worktree' into maint

Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/.  When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.

By Johan Herland (3) and Junio C Hamano (1)
* jh/notes-merge-in-git-dir-worktree:
  notes-merge: Don't remove .git/NOTES_MERGE_WORKTREE; it may be the user's cwd
  notes-merge: use opendir/readdir instead of using read_directory()
  t3310: illustrate failure to "notes merge --commit" inside $GIT_DIR/
  remove_dir_recursively(): Add flag for skipping removal of toplevel dir

Sync with 1.7.9.7

Git 1.7.9.7

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

Sync with 1.7.8.6

Git 1.7.8.6

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

Sync with 1.7.7.7

Git 1.7.7.7

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

diff --no-index: use strbuf for temporary pathnames

Instead of using limited-length buffers and risking of pathname
truncation, we should be taking advantage of strbuf API nowadays.

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

bundle: remove stray single-quote from error message

After running rev-list --boundary to retrieve the list of boundary
commits, "git bundle create" runs its own revision walk.  If in this
stage git encounters an unfamiliar option, it writes a message with an
unbalanced quotation mark:

error: unrecognized argument: --foo'

Drop the stray quote to match the "unrecognized argument: %s" message
used elsewhere and save translators some work.

This is mostly a futureproofing measure: for now, the "rev-list
--boundary" command catches most strange arguments on its own and the
above message is not seen unless you try something esoteric like "git
bundle create test.bundle --header HEAD".

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

config: reject bogus section names for --rename-section

You can feed junk to "git config --rename-section", which
will result in a config file that git will not even parse
(so you cannot fix it with git-config). We already have
syntactic sanity checks when setting a variable; let's do
the same for section names.

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

git-remote-testgit: fix race when spawning fast-import

Test "pushing to local repo" in t5800-remote-helpers can hang
due to a race condition in git-remote-testgit.  Fix it by
setting stdin to unbuffered.

On the writer side, "git push" invokes push_refs_with_export(),
which sends to stdout the command "export\n" and immediately
starts up "git fast-export".  The latter writes its output stream
to the same stdout.

On the reader side, remote helper "git-remote-testgit" reads from
stdin to get its next command.  It uses getc() to read characters
from libc up until \n.  Libc has buffered a potentially much
larger chunk of stdin.  When it sees the "export\n" command, it
forks "git fast-import" to read the stream.

If fast-export finishes before git fast-import starts, the
fast-export output can end up in libc's buffer in
git-remote-testgit, rather than in git fast-import.  The latter
hangs indefinitely on a now-empty stdin.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sequencer: remove additional blank line

Remove an additional blank line between the
headline and the list of conflicted files after
doing a recursive merge.

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fmt-merge-msg: discard needless merge parents

This is used by "git pull" to construct a merge message from list of
remote refs.  When pulling redundant set of refs, however, it did not
filter them even though the merge itself discards them as unnecessary.

Teach the command to do the same for consistency.

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

builtin/merge.c: reduce parents early

Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.

The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.

And obviously the known-to-be-broken test in t6028 is now fixed.

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

builtin/merge.c: collect other parents early

Move the code around to populate remoteheads list early in the process
before any decision regarding twohead vs octopus and fast-forwardness is
made.

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

builtin/merge.c: remove "remoteheads" global variable

Instead pass it around starting from the toplevel cmd_merge()
as an explicit parameter.

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

merge tests: octopus with redundant parents

This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD).  We've hit this while updating
master to origin/master but accidentaly we called (while being on master):

$ git merge master origin/master

Here is a minimal testcase:

$ git init a && cd a
$ echo a >a && git add a
$ git commit -minitial
$ echo b >a && git add a
$ git commit -msecond
$ git checkout master^

$ git merge master master
Fast-forwarding to: master
Already up-to-date with master
Merge made by the 'octopus' strategy.
 a |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

$ git cat-file commit HEAD
tree eebfed94e75e7760540d1485c740902590a00332
parent bd679e85202280b263e20a57639a142fa14c2c64
author Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
committer Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100

Merge branches 'master' and 'master' into HEAD

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: describe new refs based on where it came from

update_local_ref() used to say "[new branch]" when we stored a new ref
outside refs/tags/ hierarchy, but the message is more about what we
fetched, so use the refname at the origin to make that decision.

Also, only call a new ref a "branch" if it's under refs/heads/.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: Give remote_ref to update_local_ref() as well

This way, the function can look at the remote side to adjust the
informational message it gives.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: avoid stack-buffer-read-overrun for very long name

Due to the use of strncpy without explicit NUL termination,
we could end up passing names n1 or n2 that are not NUL-terminated
to queue_diff, which requires NUL-terminated strings.
Ensure that each is NUL terminated.

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cherry-pick: do not expect file arguments

If a commit-ish passed to cherry-pick or revert happens to have a file
of the same name, git complains that the argument is ambiguous and
advises to use '--'. To make things worse, the '--' argument is removed
by parse_options, und so passing '--' has no effect.

Instead, always interpret cherry-pick/revert arguments as revisions.

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

properly keep track of current working directory

Various failure modes in the repository detection code path currently
quote the wrong directory in their error message. The working directory
is changed iteratively to the parent directory until a git repository is
found. If the working directory cannot be changed to the parent
directory for some reason, the detection gives up and prints an error
message. The error message should report the current working directory.

Instead of continually updating the 'cwd' variable, which is actually
used to remember the original working directory, the 'offset' variable
is used to keep track of the current working directory. At the point
where the affected error handling code is called, 'offset' already
points to the end of the parent of the working directory, rather than
the current working directory.

Fix this by explicitly using a variable 'offset_parent' and update
'offset' concurrently with the call to chdir.

In a similar fashion, the function get_device_or_die() would print the
original working directory in case of a failure, rather than the current
working directory. Fix this as well by making use of the 'offset'
variable.

Lastly, replace the phrase 'mount parent' with 'mount point'. The former
appears to be a typo.

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

stash: use eval_gettextln correctly

Otherwise, passing an invalid option, git stash -v, gave:

git-stash: line 204: $'error: unknown option for \'stash save\':
$option\n       To provide a message, use git stash save -- \'$option\'':
command not found

Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodules: recursive fetch also checks new tags for submodule commits

Since 88a21979c (fetch/pull: recurse into submodules when necessary) all
fetched commits are examined if they contain submodule changes (unless
configuration or command line options inhibit that). If a newly recorded
submodule commit is not present in the submodule, a fetch is run inside
it to download that commit.

Checking new refs was done in an else branch where it wasn't executed for
tags. This normally isn't a problem because tags are only fetched with
the branches they live on, then checking the new commits in the fetched
branches for submodule commits will also process all tags. But when a
specific tag is fetched (or the refspec contains refs/tags/) commits only
reachable by tags won't be searched for submodule commits, which is a bug.

Fix that by moving the code outside the if/else construct to handle new
tags just like any other ref. The performance impact of adding tags that
most of the time lie on a branch which is checked anyway for new submodule
commit should be minimal, as since 6859de4 (fetch: avoid quadratic loop
checking for updated submodules) all ref-tips are collected first and then
fed to a single rev-list.

Spotted-by: Jeff King <peff@peff.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: use newer curl options for setting credentials

We give the username and password to curl by sticking them
in a buffer of the form "user:pass" and handing the result
to CURLOPT_USERPWD. Since curl 7.19.1, there is a split
mechanism, where you can specify each element individually.

This has the advantage that a username can contain a ":"
character. It also is less code for us, since we can hand
our strings over to curl directly. And since curl 7.17.0 and
higher promise to copy the strings for us, we we don't even
have to worry about memory ownership issues.

Unfortunately, we have to keep the ugly code for old curl
around, but as it is now nicely #if'd out, we can easily get
rid of it when we decide that 7.19.1 is "old enough".

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

http: clean up leak in init_curl_http_auth

When we have a credential to give to curl, we must copy it
into a "user:pass" buffer and then hand the buffer to curl.
Old versions of curl did not copy the buffer, and we were
expected to keep it valid. Newer versions of curl will copy
the buffer.

Our solution was to use a strbuf and detach it, giving
ownership of the resulting buffer to curl. However, this
meant that we were leaking the buffer on newer versions of
curl, since curl was just copying it and throwing away the
string we passed. Furthermore, when we replaced a
credential (e.g., because our original one was rejected), we
were also leaking on both old and new versions of curl.

This got even worse in the last patch, which started
replacing the credential (and thus leaking) on every http
request.

Instead, let's use a static buffer to make the ownership
more clear and less leaky.  We already keep a static "struct
credential", so we are only handling a single credential at
a time, anyway.

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

l10n: Add Danish team (da) to list of teams

l10n: New da.po file with 0 translations

blame: accept --need-minimal

Between v1.7.1 and v1.7.2, 582aa00bdffb switched the default "diff"
invocation not to use XDF_NEED_MINIMAL, but this breaks "git blame"
rather badly.

Allow the command line option to ask for an extra careful matching.

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

l10n: Updated pt_PT language

remote-curl: main test case for the OS command line overflow

This is main test case for the original problem that triggered this
patch series. We create a repo with 50k tags and then test whether
git-clone over the smart HTTP protocol succeeds.

Note that we construct the repo in a slightly different way than the
original script used to reproduce the problem. This is because the
original script just created 50k tags all pointing to the same commit,
so if there was a bug where remote-curl.c was not passing all the refs
to fetch-pack we wouldn't know. The clone would succeed even if only one
tag was passed, because all the other tags were pointing at the same SHA
and would be considered present.

Instead we create a repo with 50k independent (dangling) commits and
then tag each of those commits with a unique tag. This way if one of the
tags is not given to fetch-pack, later stages of the clone would
complain about it.

This allows us to test both that the command line overflow was fixed, as
well as that it was fixed in a way that doesn't leave out any of the
refs.

Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: test cases for the new --stdin option

These test cases focus only on testing the parsing of refs on stdin,
without bothering with the rest of the fetch-pack machinery. We pass in
the refs using different combinations of command line and stdin and then
we watch fetch-pack's stdout to see whether it prints all the refs we
specified (but we ignore their order).

Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-curl: send the refs to fetch-pack on stdin

Now that we can throw an arbitrary number of refs at fetch-pack using
its --stdin option, we use it in the remote-curl helper to bypass the
OS command line length limit.

Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-import: tighten parsing of datarefs

The syntax for the use of mark references in fast-import
demands either a SP (space) or LF (end-of-line) after
a mark reference.  Fast-import does not complain when garbage
appears after a mark reference in some cases.

Factor out parsing of mark references and complain if
errant characters are found.  Also be a little more careful
when parsing "inline" and SHA1s, complaining if extra
characters appear or if the form of the dataref is unrecognized.

Buggy input can cause fast-import to produce the wrong output,
silently, without error.  This makes it difficult to track
down buggy generators of fast-import streams.  An example is
seen in the last line of this commit command:

    commit refs/heads/S2
    committer Name <name@example.com> 1112912893 -0400
    data <<COMMIT
    commit message
    COMMIT
    from :1M 100644 :103 hello.c

It is missing a newline and should be:

    [...]
    from :1
    M 100644 :103 hello.c

What fast-import does is to produce a commit with the same
contents for hello.c as in refs/heads/S2^.  What the buggy
program was expecting was the contents of blob :103.  While
the resulting commit graph looked correct, the contents in
some commits were wrong.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.7.9' into maint

* maint-1.7.9:

Merge branch 'maint-1.7.8' into maint-1.7.9

* maint-1.7.8:
  Documentation/gitweb: trivial English fixes
  fetch/receive: remove over-pessimistic connectivity check

test-subprocess: fix segfault without arguments

Check if we even have a parameter before checking its value.  Running
this command without any arguments may not make a lot of sense, but
reacting with a segmentation fault is unduly harsh.

While we're at it, avoid casting argv by declaring it const right away.

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

submodule: fix prototype of gitmodules_config

Add void to make it match its definition in submodule.c.

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

fix http auth with multiple curl handles

HTTP authentication is currently handled by get_refs and fetch_ref, but
not by fetch_object, fetch_pack or fetch_alternates. In the
single-threaded case, this is not an issue, since get_refs is always
called first. It recognigzes the 401 and prompts the user for
credentials, which will then be used subsequently.

If the curl multi interface is used, however, only the multi handle used
by get_refs will have credentials configured. Requests made by other
handles fail with an authentication error.

Fix this by setting CURLOPT_USERPWD whenever a slot is requested.

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

http auth fails with multiple curl handles

Create a repo with multiple loose objects in order to demonstrate http
authentication breakage.

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

rebase -i continue: don't skip commits that only change submodules

When git-rebase--interactive stops due to a conflict and the only change
to be committed is in a submodule, the test for whether there is
anything to be committed ignores the staged submodule change.  This
leads rebase to skip creating the commit for the change.

While unstaged submodule changes should be ignored to avoid needing to
update submodules during a rebase, it is safe to remove the
--ignore-submodules option to diff-index because --cached ensures that
it is only checking the index.  This was discussed in [1] and a test is
included to ensure that unstaged changes are still ignored correctly.

[1] http://thread.gmane.org/gmane.comp.version-control.git/188713

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/maint-verify-objects-remove-pessimism' into maint-1.7.8

* jc/maint-verify-objects-remove-pessimism:
  fetch/receive: remove over-pessimistic connectivity check

Merge branch 'dw/gitweb-doc-grammo' into maint-1.7.8

* dw/gitweb-doc-grammo:
  Documentation/gitweb: trivial English fixes

Merge branch 'tr/cache-tree' into maint-1.7.8

* tr/cache-tree:
  t0090: be prepared that 'wc -l' writes leading blanks
  reset: update cache-tree data when appropriate
  commit: write cache-tree data when writing index anyway
  Refactor cache_tree_update idiom from commit
  Test the current state of the cache-tree optimization
  Add test-scrap-cache-tree

Merge branch 'cb/maint-t5541-make-server-port-portable' into maint-1.7.8

* cb/maint-t5541-make-server-port-portable:
  t5541: check error message against the real port number used
  remote-curl: Fix push status report when all branches fail

Merge branch 'cn/maint-rev-list-doc' into maint-1.7.8

* cn/maint-rev-list-doc:
  Documentation: use {asterisk} in rev-list-options.txt when needed

Merge branch 'tr/maint-bundle-boundary' into maint-1.7.8

* tr/maint-bundle-boundary:
  bundle: keep around names passed to add_pending_object()
  t5510: ensure we stay in the toplevel test dir
  t5510: refactor bundle->pack conversion

Merge branch 'tr/maint-bundle-long-subject' into maint-1.7.8

* tr/maint-bundle-long-subject:
  t5704: match tests to modern style
  strbuf: improve strbuf_get*line documentation
  bundle: use a strbuf to scan the log for boundary commits
  bundle: put strbuf_readline_fd in strbuf.c with adjustments

Merge branch 'ph/rerere-doc' into maint-1.7.8

* ph/rerere-doc:
  rerere: Document 'rerere remaining'

Git 1.7.10

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

spec: add missing build dependency

Otherwise:

/usr/bin/perl Makefile.PL PREFIX='/opt/git' INSTALL_BASE=''
Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: ...) at Makefile.PL line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.
make[1]: *** [perl.mak] Error 2
make: *** [perl/perl.mak] Error 2

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

run-command: treat inaccessible directories as ENOENT

When execvp reports EACCES, it can be one of two things:

  1. We found a file to execute, but did not have
     permissions to do so.

  2. We did not have permissions to look in some directory
     in the $PATH.

In the former case, we want to consider this a
permissions problem and report it to the user as such (since
getting this for something like "git foo" is likely a
configuration error).

In the latter case, there is a good chance that the
inaccessible directory does not contain anything of
interest. Reporting "permission denied" is confusing to the
user (and prevents our usual "did you mean...?" lookup). It
also prevents git from trying alias lookup, since we do so
only when an external command does not exist (not when it
exists but has an error).

This patch detects EACCES from execvp, checks whether we are
in case (2), and if so converts errno to ENOENT. This
behavior matches that of "bash" (but not of simpler shells
that use execvp more directly, like "dash").

Test stolen from Junio.

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

compat/mingw.[ch]: Change return type of exec functions to int

The POSIX standard specifies a return type of int for all six exec
functions. In addition, all exec functions return -1 on error, and
simply do not return on success. However, the current emulation of
the exec functions on mingw are declared with a void return type.

This would cause a problem should any code attempt to call the
exec function in a non-void context. In particular, if an exec
function were used in a conditional it would fail to compile.

In order to improve the fidelity of the emulation, we change the
return type of the mingw_execv[p] functions to int and return -1
on error.

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

push: error out when the "upstream" semantics does not make sense

The user can say "git push" without specifying any refspec.  When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.

However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:

 - The current branch does not have branch.$name.remote configured.  By
   definition, "git push" that does not name where to push to will not
   know where to push to.  The user may explicitly say "git push $there",
   but again, by definition, no branch at repository $there is set to
   integrate with the current branch in this case and we wouldn't know
   which remote branch to update.

 - The current branch does have branch.$name.remote configured, but it
   does not specify branch.$name.merge that names what branch at the
   remote this branch integrates with. "git push" knows where to push in
   this case (or the user may explicitly say "git push $remote" to tell us
   where to push), but we do not know which remote branch to update.

 - The current branch does have its remote and upstream branch configured,
   but the user said "git push $there", where $there is not the remote
   named by "branch.$name.remote".  By definition, no branch at repository
   $there is set to integrate with the current branch in this case, and
   this push is not meant to update any branch at the remote repository
   $there.

The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.

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

add--interactive: ignore unmerged entries in patch mode

When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").

The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.

We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field.  Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).

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

Documentation/git-commit: rephrase the "initial-ness" of templates

The description of "commit -t <file>" said the file is used "as the
initial version" of the commit message, but in the context of an SCM,
"version" is a loaded word that can needlesslyl confuse readers.

Explain the purpose of the mechanism without using "version".

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

Git 1.7.10-rc4

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

Merge branch 'pt/gitk'

* pt/gitk:
  gitk: fix setting font display with new tabbed dialog layout.
  gitk: fix tabbed preferences construction when using tcl 8.4

fetch-pack: new --stdin option to read refs from stdin

If a remote repo has too many tags (or branches), cloning it over the
smart HTTP transport can fail because remote-curl.c puts all the refs
from the remote repo on the fetch-pack command line. This can make the
command line longer than the global OS command line limit, causing
fetch-pack to fail.

This is especially a problem on Windows where the command line limit is
orders of magnitude shorter than Linux. There are already real repos out
there that msysGit cannot clone over smart HTTP due to this problem.

Here is an easy way to trigger this problem:

git init too-many-refs
cd too-many-refs
echo bla > bla.txt
git add .
git commit -m test
sha=$(git rev-parse HEAD)
tag=$(perl -e 'print "bla" x 30')
for i in `seq 50000`; do
echo $sha refs/tags/$tag-$i >> .git/packed-refs
done

Then share this repo over the smart HTTP protocol and try cloning it:

$ git clone http://localhost/.../too-many-refs/.git
Cloning into 'too-many-refs'...
fatal: cannot exec 'fetch-pack': Argument list too long

50k tags is obviously an absurd number, but it is required to
demonstrate the problem on Linux because it has a much more generous
command line limit. On Windows the clone fails with as little as 500
tags in the above loop, which is getting uncomfortably close to the
number of tags you might see in real long lived repos.

This is not just theoretical, msysGit is already failing to clone our
company repo due to this. It's a large repo converted from CVS, nearly
10 years of history.

Four possible solutions were discussed on the Git mailing list (in no
particular order):

1) Call fetch-pack multiple times with smaller batches of refs.

This was dismissed as inefficient and inelegant.

2) Add option --refs-fd=$n to pass a an fd from where to read the refs.

This was rejected because inheriting descriptors other than
stdin/stdout/stderr through exec() is apparently problematic on Windows,
plus it would require changes to the run-command API to open extra
pipes.

3) Add option --refs-from=$tmpfile to pass the refs using a temp file.

This was not favored because of the temp file requirement.

4) Add option --stdin to pass the refs on stdin, one per line.

In the end this option was chosen as the most efficient and most
desirable from scripting perspective.

There was however a small complication when using stdin to pass refs to
fetch-pack. The --stateless-rpc option to fetch-pack also uses stdin for
communication with the remote server.

If we are going to sneak refs on stdin line by line, it would have to be
done very carefully in the presence of --stateless-rpc, because when
reading refs line by line we might read ahead too much data into our
buffer and eat some of the remote protocol data which is also coming on
stdin.

One way to solve this would be to refactor get_remote_heads() in
fetch-pack.c to accept a residual buffer from our stdin line parsing
above, but this function is used in several places so other callers
would be burdened by this residual buffer interface even when most of
them don't need it.

In the end we settled on the following solution:

If --stdin is specified without --stateless-rpc, fetch-pack would read
the refs from stdin one per line, in a script friendly format.

However if --stdin is specified together with --stateless-rpc,
fetch-pack would read the refs from stdin in packetized format
(pkt-line) with a flush packet terminating the list of refs. This way we
can read the exact number of bytes that we need from stdin, and then
get_remote_heads() can continue reading from the same fd without losing
a single byte of remote protocol data.

This way the --stdin option only loses generality and scriptability when
used together with --stateless-rpc, which is not easily scriptable
anyway because it also uses pkt-line when talking to the remote server.

Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with 1.7.9.6

Git 1.7.9.6

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