gitweb.git
restore_env(): free the saved environment variable... Junio C Hamano Tue, 2 Feb 2016 23:42:59 +0000 (15:42 -0800)

restore_env(): free the saved environment variable once we are done

Just like we free orig_cwd, which is the value of the original
working directory saved in save_env_before_alias(), once we are
done with it, the contents of orig_env[] array, saved in the
save_env_before_alias() function should be freed; otherwise,
the second and subsequent calls to save/restore pair will leak
the memory allocated in save_env_before_alias().

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

git: simplify environment save/restore logicJunio C Hamano Wed, 27 Jan 2016 06:52:02 +0000 (22:52 -0800)

git: simplify environment save/restore logic

The only code that cares about the value of the global variable
saved_env_before_alias after the previous fix is handle_builtin()
that turns into a glorified no-op when the variable is true, so the
logic could safely be lifted to its caller, i.e. the caller can
refrain from calling it when the variable is set.

This variable tells us if save_env_before_alias() was called (with
or without matching restore_env()), but the sole caller of the
function, handle_alias(), always calls it as the first thing, so we
can consider that the variable essentially keeps track of the fact
that handle_alias() has ever been called.

It turns out that handle_builtin() and handle_alias() are called
only from one function in a way that the value of the variable
matters, which is run_argv(), and it already keeps track of the
fact that it already called handle_alias().

So we can simplify the whole thing by:

- Change handle_builtin() to always make a direct call to the
builtin implementation it finds, and make sure the caller
refrains from calling it if handle_alias() has ever been
called;

- Remove saved_env_before_alias variable, and instead use the
local "done_alias" variable maintained inside run_argv() to
make the same decision.

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

git: protect against unbalanced calls to {save,restore... Junio C Hamano Wed, 27 Jan 2016 06:50:27 +0000 (22:50 -0800)

git: protect against unbalanced calls to {save,restore}_env()

We made sure that save_env_before_alias() does not skip saving the
environment when asked to (which led to use-after-free of orig_cwd
in restore_env() in the buggy version) with the previous step.

Protect against future breakage where somebody adds new callers of
these functions in an unbalanced fashion.

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

git: remove an early return from save_env_before_alias()Junio C Hamano Tue, 26 Jan 2016 19:46:53 +0000 (11:46 -0800)

git: remove an early return from save_env_before_alias()

When help.autocorrect is in effect, an attempt to auto-execute an
uniquely corrected result of a misspelt alias will result in an
irrelevant error message. The codepath that causes this calls
save_env_before_alias() and restore_env() in handle_alias(), and
that happens twice. A global variable orig_cwd is allocated to hold
the return value of getcwd() in save_env_before_alias(), which is
then used in restore_env() to go back to that directory and finally
free(3)'d there.

However, save_env_before_alias() is not prepared to be called twice.
It returns early when it knows it has already been called, leaving
orig_cwd undefined, which is then checked in the second call to
restore_env(), and by that time, the memory that used to hold the
contents of orig_cwd is either freed or reused to hold something
else, and this is fed to chdir(2), causing it to fail. Even if it
did not fail (i.e. reading of the already free'd piece of memory
yielded a directory path that we can chdir(2) to), it then gets
free(3)'d.

Fix this by making sure save_env() does do the saving when called.

While at it, add a minimal test for help.autocorrect facility.

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

run-command: don't warn on SIGPIPE deathsJeff King Tue, 29 Dec 2015 08:12:22 +0000 (03:12 -0500)

run-command: don't warn on SIGPIPE deaths

When git executes a sub-command, we print a warning if the
command dies due to a signal, but make an exception for
"uninteresting" cases like SIGINT and SIGQUIT (since the
user presumably just hit ^C).

We should make a similar exception for SIGPIPE, because it's
an expected and uninteresting return in most cases; it
generally means the user quit the pager before git had
finished generating all output. This used to be very hard
to trigger in practice, because:

1. We only complain if we see a real SIGPIPE death, not
the shell-induced 141 exit code. This means that
anything we run via the shell does not trigger the
warning, which includes most non-trivial aliases.

2. The common case for SIGPIPE is the user quitting the
pager before git has finished generating all output.
But if the user triggers a pager with "-p", we redirect
the git wrapper's stderr to that pager, too. Since the
pager is dead, it means that the message goes nowhere.

3. You can see it if you run your own pager, like
"git foo | head". But that only happens if "foo" is a
non-builtin (so it doesn't work with "log", for
example).

However, it may become more common after 86d26f2, which
teaches alias to re-exec builtins rather than running them
in the same process. This case doesn't trigger (1), as we
don't need a shell to run a git command. It doesn't trigger
(2), because the pager is not started by the original git,
but by the inner re-exec of git. And it doesn't trigger (3),
because builtins are treated more like non-builtins in this
case.

Given how flaky this message already is (e.g., you cannot
even know whether you will see it, as git optimizes out some
shell invocations behind the scenes based on the contents of
the command!), and that it is unlikely to ever provide
useful information, let's suppress it for all cases of
SIGPIPE.

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

git.c: make sure we do not leak GIT_* to alias scriptsNguyễn Thái Ngọc Duy Sun, 20 Dec 2015 07:50:19 +0000 (14:50 +0700)

git.c: make sure we do not leak GIT_* to alias scripts

The unfortunate commit d95138e (setup: set env $GIT_WORK_TREE when
work tree is set, like $GIT_DIR - 2015-06-26) exposes another problem,
besides git-clone that's described in the previous commit. If
GIT_WORK_TREE (or even GIT_DIR) is exported to an alias script, it may
mislead git commands in the script where the repo is. Granted, most
scripts work on the repo where the alias is summoned from. But nowhere
do we forbid the script to visit another repository.

The revert of d95138e in the previous commit is sufficient as a
fix. However, to protect us from accidentally leaking GIT_*
environment variables again, we restore certain sensitive env before
calling the external script.

GIT_PREFIX is let through because there's another setup side effect
that we simply accepted so far: current working directory is
moved. Maybe in future we can introduce a new alias format that
guarantees no cwd move, then we can unexport GIT_PREFIX.

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

setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE... Nguyễn Thái Ngọc Duy Sun, 20 Dec 2015 07:50:18 +0000 (14:50 +0700)

setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

Commit d95138e [1] attempted to fix a .git file problem by
setting GIT_WORK_TREE whenever GIT_DIR is set. It sounded harmless
because we handle GIT_DIR and GIT_WORK_TREE side by side for most
commands, with two exceptions: git-init and git-clone.

"git clone" is not happy with d95138e. This command ignores GIT_DIR
but respects GIT_WORK_TREE [2] [3] which means it used to run fine
from a hook, where GIT_DIR was set but GIT_WORK_TREE was not (*).
With d95138e, GIT_WORK_TREE is set all the time and git-clone
interprets that as "I give you order to put the worktree here",
usually against the user's intention.

The solution in d95138e is reverted earlier, and instead we reuse
the solution from c056261 [4]. It fixed another setup-messed-
up-by-alias by saving and restoring env and spawning a new process,
but for git-clone and git-init only.

Now we conclude that setup-messed-up-by-alias is always evil. So the
env restoration is done for _all_ commands, including external ones,
whenever aliases are involved. It fixes what d95138e tried to fix,
without upsetting git-clone-inside-hooks.

The test from d95138e remains to verify it's not broken by this. A new
test is added to make sure git-clone-inside-hooks remains happy.

(*) GIT_WORK_TREE was not set _most of the time_. In some cases
GIT_WORK_TREE is set and git-clone will behave differently. The
use of GIT_WORK_TREE to direct git-clone to put work tree
elsewhere looks like a mistake because it causes surprises this
way. But that's a separate story.

[1] d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like
$GIT_DIR - 2015-06-26)
[2] 2beebd2 (clone: create intermediate directories of destination
repo - 2008-06-25)
[3] 20ccef4 (make git-clone GIT_WORK_TREE aware - 2007-07-06)
[4] c056261 (git potty: restore environments after alias expansion -
2014-06-08)

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

git.c: make it clear save_env() is for alias handling... Nguyễn Thái Ngọc Duy Thu, 3 Dec 2015 18:17:55 +0000 (19:17 +0100)

git.c: make it clear save_env() is for alias handling only

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

Merge branch 'nd/stop-setenv-work-tree' into nd/clear... Junio C Hamano Tue, 22 Dec 2015 21:39:47 +0000 (13:39 -0800)

Merge branch 'nd/stop-setenv-work-tree' into nd/clear-gitenv-upon-use-of-alias

* nd/stop-setenv-work-tree:
Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

Revert "setup: set env $GIT_WORK_TREE when work tree... Nguyễn Thái Ngọc Duy Mon, 21 Dec 2015 10:22:52 +0000 (17:22 +0700)

Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

This reverts d95138e6 (setup: set env $GIT_WORK_TREE when work tree
is set, like $GIT_DIR, 2015-06-26).

It has caused three regression reports so far.

http://article.gmane.org/gmane.comp.version-control.git/281608
http://article.gmane.org/gmane.comp.version-control.git/281979
http://article.gmane.org/gmane.comp.version-control.git/282691

All of them are about spawning git subprocesses, where the new
presence of GIT_WORK_TREE either changes command behaviour (git-init
or git-clone), or how repo/worktree is detected (from aliases), with
or without $GIT_DIR.

The original bug will be re-fixed another way.

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

Git 2.5.4 v2.5.4Junio C Hamano Mon, 28 Sep 2015 22:26:49 +0000 (15:26 -0700)

Git 2.5.4

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

Sync with 2.4.10Junio C Hamano Mon, 28 Sep 2015 22:33:56 +0000 (15:33 -0700)

Sync with 2.4.10

Git 2.4.10 v2.4.10Junio C Hamano Mon, 28 Sep 2015 22:29:54 +0000 (15:29 -0700)

Git 2.4.10

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

Sync with 2.3.10Junio C Hamano Mon, 28 Sep 2015 22:28:26 +0000 (15:28 -0700)

Sync with 2.3.10

Git 2.3.10 v2.3.10Junio C Hamano Mon, 28 Sep 2015 22:00:37 +0000 (15:00 -0700)

Git 2.3.10

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

Merge branch 'jk/xdiff-memory-limits' into maint-2.3Junio C Hamano Mon, 28 Sep 2015 21:59:28 +0000 (14:59 -0700)

Merge branch 'jk/xdiff-memory-limits' into maint-2.3

merge-file: enforce MAX_XDIFF_SIZE on incoming filesJeff King Fri, 25 Sep 2015 21:58:09 +0000 (17:58 -0400)

merge-file: enforce MAX_XDIFF_SIZE on incoming files

The previous commit enforces MAX_XDIFF_SIZE at the
interfaces to xdiff: xdi_diff (which calls xdl_diff) and
ll_xdl_merge (which calls xdl_merge).

But we have another direct call to xdl_merge in
merge-file.c. If it were written today, this probably would
just use the ll_merge machinery. But it predates that code,
and uses slightly different options to xdl_merge (e.g.,
ZEALOUS_ALNUM).

We could try to abstract out an xdi_merge to match the
existing xdi_diff, but even that is difficult. Rather than
simply report error, we try to treat large files as binary,
and that distinction would happen outside of xdi_merge.

The simplest fix is to just replicate the MAX_XDIFF_SIZE
check in merge-file.c.

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

xdiff: reject files larger than ~1GBJeff King Thu, 24 Sep 2015 23:12:45 +0000 (19:12 -0400)

xdiff: reject files larger than ~1GB

The xdiff code is not prepared to handle extremely large
files. It uses "int" in many places, which can overflow if
we have a very large number of lines or even bytes in our
input files. This can cause us to produce incorrect diffs,
with no indication that the output is wrong. Or worse, we
may even underallocate a buffer whose size is the result of
an overflowing addition.

We're much better off to tell the user that we cannot diff
or merge such a large file. This patch covers both cases,
but in slightly different ways:

1. For merging, we notice the large file and cleanly fall
back to a binary merge (which is effectively "we cannot
merge this").

2. For diffing, we make the binary/text distinction much
earlier, and in many different places. For this case,
we'll use the xdi_diff as our choke point, and reject
any diff there before it hits the xdiff code.

This means in most cases we'll die() immediately after.
That's not ideal, but in practice we shouldn't
generally hit this code path unless the user is trying
to do something tricky. We already consider files
larger than core.bigfilethreshold to be binary, so this
code would only kick in when that is circumvented
(either by bumping that value, or by using a
.gitattribute to mark a file as diffable).

In other words, we can avoid being "nice" here, because
there is already nice code that tries to do the right
thing. We are adding the suspenders to the nice code's
belt, so notice when it has been worked around (both to
protect the user from malicious inputs, and because it
is better to die() than generate bogus output).

The maximum size was chosen after experimenting with feeding
large files to the xdiff code. It's just under a gigabyte,
which leaves room for two obvious cases:

- a diff3 merge conflict result on files of maximum size X
could be 3*X plus the size of the markers, which would
still be only about 3G, which fits in a 32-bit int.

- some of the diff code allocates arrays of one int per
record. Even if each file consists only of blank lines,
then a file smaller than 1G will have fewer than 1G
records, and therefore the int array will fit in 4G.

Since the limit is arbitrary anyway, I chose to go under a
gigabyte, to leave a safety margin (e.g., we would not want
to overflow by allocating "(records + 1) * sizeof(int)" or
similar.

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

react to errors in xdi_diffJeff King Thu, 24 Sep 2015 23:12:23 +0000 (19:12 -0400)

react to errors in xdi_diff

When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later. This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).

In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper). But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.

Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.

We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).

There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.

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

Merge branch 'jk/transfer-limit-redirection' into maint-2.3Junio C Hamano Mon, 28 Sep 2015 21:46:05 +0000 (14:46 -0700)

Merge branch 'jk/transfer-limit-redirection' into maint-2.3

Merge branch 'jk/transfer-limit-protocol' into maint-2.3Junio C Hamano Mon, 28 Sep 2015 21:33:27 +0000 (14:33 -0700)

Merge branch 'jk/transfer-limit-protocol' into maint-2.3

http: limit redirection depthBlake Burkhart Tue, 22 Sep 2015 22:06:20 +0000 (18:06 -0400)

http: limit redirection depth

By default, libcurl will follow circular http redirects
forever. Let's put a cap on this so that somebody who can
trigger an automated fetch of an arbitrary repository (e.g.,
for CI) cannot convince git to loop infinitely.

The value chosen is 20, which is the same default that
Firefox uses.

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

http: limit redirection to protocol-whitelistBlake Burkhart Tue, 22 Sep 2015 22:06:04 +0000 (18:06 -0400)

http: limit redirection to protocol-whitelist

Previously, libcurl would follow redirection to any protocol
it was compiled for support with. This is desirable to allow
redirection from HTTP to HTTPS. However, it would even
successfully allow redirection from HTTP to SFTP, a protocol
that git does not otherwise support at all. Furthermore
git's new protocol-whitelisting could be bypassed by
following a redirect within the remote helper, as it was
only enforced at transport selection time.

This patch limits redirects within libcurl to HTTP, HTTPS,
FTP and FTPS. If there is a protocol-whitelist present, this
list is limited to those also allowed by the whitelist. As
redirection happens from within libcurl, it is impossible
for an HTTP redirect to a protocol implemented within
another remote helper.

When the curl version git was compiled with is too old to
support restrictions on protocol redirection, we warn the
user if GIT_ALLOW_PROTOCOL restrictions were requested. This
is a little inaccurate, as even without that variable in the
environment, we would still restrict SFTP, etc, and we do
not warn in that case. But anything else means we would
literally warn every time git accesses an http remote.

This commit includes a test, but it is not as robust as we
would hope. It redirects an http request to ftp, and checks
that curl complained about the protocol, which means that we
are relying on curl's specific error message to know what
happened. Ideally we would redirect to a working ftp server
and confirm that we can clone without protocol restrictions,
and not with them. But we do not have a portable way of
providing an ftp server, nor any other protocol that curl
supports (https is the closest, but we would have to deal
with certificates).

[jk: added test and version warning]

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

transport: refactor protocol whitelist codeJeff King Tue, 22 Sep 2015 22:03:49 +0000 (18:03 -0400)

transport: refactor protocol whitelist code

The current callers only want to die when their transport is
prohibited. But future callers want to query the mechanism
without dying.

Let's break out a few query functions, and also save the
results in a static list so we don't have to re-parse for
each query.

Based-on-a-patch-by: Blake Burkhart <bburky@bburky.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: allow only certain protocols for submodule... Jeff King Wed, 16 Sep 2015 17:13:12 +0000 (13:13 -0400)

submodule: allow only certain protocols for submodule fetches

Some protocols (like git-remote-ext) can execute arbitrary
code found in the URL. The URLs that submodules use may come
from arbitrary sources (e.g., .gitmodules files in a remote
repository). Let's restrict submodules to fetching from a
known-good subset of protocols.

Note that we apply this restriction to all submodule
commands, whether the URL comes from .gitmodules or not.
This is more restrictive than we need to be; for example, in
the tests we run:

git submodule add ext::...

which should be trusted, as the URL comes directly from the
command line provided by the user. But doing it this way is
simpler, and makes it much less likely that we would miss a
case. And since such protocols should be an exception
(especially because nobody who clones from them will be able
to update the submodules!), it's not likely to inconvenience
anyone in practice.

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

transport: add a protocol-whitelist environment variableJeff King Wed, 16 Sep 2015 17:12:52 +0000 (13:12 -0400)

transport: add a protocol-whitelist environment variable

If we are cloning an untrusted remote repository into a
sandbox, we may also want to fetch remote submodules in
order to get the complete view as intended by the other
side. However, that opens us up to attacks where a malicious
user gets us to clone something they would not otherwise
have access to (this is not necessarily a problem by itself,
but we may then act on the cloned contents in a way that
exposes them to the attacker).

Ideally such a setup would sandbox git entirely away from
high-value items, but this is not always practical or easy
to set up (e.g., OS network controls may block multiple
protocols, and we would want to enable some but not others).

We can help this case by providing a way to restrict
particular protocols. We use a whitelist in the environment.
This is more annoying to set up than a blacklist, but
defaults to safety if the set of protocols git supports
grows). If no whitelist is specified, we continue to default
to allowing all protocols (this is an "unsafe" default, but
since the minority of users will want this sandboxing
effect, it is the only sensible one).

A note on the tests: ideally these would all be in a single
test file, but the git-daemon and httpd test infrastructure
is an all-or-nothing proposition rather than a test-by-test
prerequisite. By putting them all together, we would be
unable to test the file-local code on machines without
apache.

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

Git 2.5.3 v2.5.3Junio C Hamano Thu, 17 Sep 2015 19:16:10 +0000 (12:16 -0700)

Git 2.5.3

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

Merge branch 'dt/untracked-subdir' into maintJunio C Hamano Thu, 17 Sep 2015 19:12:29 +0000 (12:12 -0700)

Merge branch 'dt/untracked-subdir' into maint

The experimental untracked-cache feature were buggy when paths with
a few levels of subdirectories are involved.

* dt/untracked-subdir:
untracked cache: fix entry invalidation
untracked-cache: fix subdirectory handling
t7063: use --force-untracked-cache to speed up a bit
untracked-cache: support sparse checkout

Merge branch 'br/svn-doc-include-paths-config' into... Junio C Hamano Thu, 17 Sep 2015 19:11:46 +0000 (12:11 -0700)

Merge branch 'br/svn-doc-include-paths-config' into maint

* br/svn-doc-include-paths-config:
git-svn doc: mention "svn-remote.<name>.include-paths"

Merge branch 'ah/submodule-typofix-in-error' into maintJunio C Hamano Thu, 17 Sep 2015 19:11:06 +0000 (12:11 -0700)

Merge branch 'ah/submodule-typofix-in-error' into maint

Error string fix.

* ah/submodule-typofix-in-error:
git-submodule: remove extraneous space from error message

Merge branch 'js/maint-am-skip-performance-regression... Junio C Hamano Thu, 17 Sep 2015 19:03:02 +0000 (12:03 -0700)

Merge branch 'js/maint-am-skip-performance-regression' into maint

* js/maint-am-skip-performance-regression:
am --skip/--abort: merge HEAD/ORIG_HEAD tree into index

am --skip/--abort: merge HEAD/ORIG_HEAD tree into indexJohannes Schindelin Wed, 9 Sep 2015 09:10:07 +0000 (09:10 +0000)

am --skip/--abort: merge HEAD/ORIG_HEAD tree into index

f8da6801 (am --skip: support skipping while on unborn branch,
2015-06-06) introduced a performance regression to "git am --skip",
where it used "read-tree" to reconstruct the index from scratch
without reusing the cached stat information.

This is a backport of the corresponding patch to the builtin am in 2.6:
3ecc704 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index,
2015-08-19).

Reportedly, it can make a huge difference on Windows, in one case a `git
rebase --skip` took 1m40s without, and 5s with, this patch.

cf. https://github.com/git-for-windows/git/issues/365

Reported-and-suggested-by: Kim Gybels <kgybels@infogroep.be>
Acked-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.5.2 v2.5.2Junio C Hamano Fri, 4 Sep 2015 17:46:00 +0000 (10:46 -0700)

Git 2.5.2

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

Sync with 2.4.9Junio C Hamano Fri, 4 Sep 2015 17:43:23 +0000 (10:43 -0700)

Sync with 2.4.9

Git 2.4.9 v2.4.9Junio C Hamano Fri, 4 Sep 2015 17:36:00 +0000 (10:36 -0700)

Git 2.4.9

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

Sync with 2.3.9Junio C Hamano Fri, 4 Sep 2015 17:34:19 +0000 (10:34 -0700)

Sync with 2.3.9

Git 2.3.9 v2.3.9Junio C Hamano Fri, 4 Sep 2015 17:31:34 +0000 (10:31 -0700)

Git 2.3.9

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

Sync with 2.2.3Junio C Hamano Fri, 4 Sep 2015 17:29:28 +0000 (10:29 -0700)

Sync with 2.2.3

Git 2.2.3 v2.2.3Junio C Hamano Fri, 4 Sep 2015 17:25:47 +0000 (10:25 -0700)

Git 2.2.3

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

Merge branch 'jk/long-paths' into maint-2.2Junio C Hamano Fri, 4 Sep 2015 17:25:23 +0000 (10:25 -0700)

Merge branch 'jk/long-paths' into maint-2.2

show-branch: use a strbuf for reflog descriptionsJeff King Wed, 19 Aug 2015 18:12:48 +0000 (14:12 -0400)

show-branch: use a strbuf for reflog descriptions

When we show "branch@{0}", we format into a fixed-size
buffer using sprintf. This can overflow if you have long
branch names. We can fix it by using a temporary strbuf.

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

read_info_alternates: handle paths larger than PATH_MAXJeff King Wed, 19 Aug 2015 18:12:45 +0000 (14:12 -0400)

read_info_alternates: handle paths larger than PATH_MAX

This function assumes that the relative_base path passed
into it is no larger than PATH_MAX, and writes into a
fixed-size buffer. However, this path may not have actually
come from the filesystem; for example, add_submodule_odb
generates a path using a strbuf and passes it in. This is
hard to trigger in practice, though, because the long
submodule directory would have to exist on disk before we
would try to open its info/alternates file.

We can easily avoid the bug, though, by simply creating the
filename on the heap.

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

notes: use a strbuf in add_non_noteJeff King Wed, 19 Aug 2015 18:12:41 +0000 (14:12 -0400)

notes: use a strbuf in add_non_note

When we are loading a notes tree into our internal hash
table, we also collect any files that are clearly non-notes.
We format the name of the file into a PATH_MAX buffer, but
unlike true notes (which cannot be larger than a fanned-out
sha1 hash), these tree entries can be arbitrarily long,
overflowing our buffer.

We can fix this by switching to a strbuf. It doesn't even
cost us an extra allocation, as we can simply hand ownership
of the buffer over to the non-note struct.

This is of moderate security interest, as you might fetch
notes trees from an untrusted remote. However, we do not do
so by default, so you would have to manually fetch into the
notes namespace.

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

verify_absent: allow filenames longer than PATH_MAXJeff King Wed, 19 Aug 2015 18:12:37 +0000 (14:12 -0400)

verify_absent: allow filenames longer than PATH_MAX

When unpack-trees wants to know whether a path will
overwrite anything in the working tree, we use lstat() to
see if there is anything there. But if we are going to write
"foo/bar", we can't just lstat("foo/bar"); we need to look
for leading prefixes (e.g., "foo"). So we use the lstat cache
to find the length of the leading prefix, and copy the
filename up to that length into a temporary buffer (since
the original name is const, we cannot just stick a NUL in
it).

The copy we make goes into a PATH_MAX-sized buffer, which
will overflow if the prefix is longer than PATH_MAX. How
this happens is a little tricky, since in theory PATH_MAX is
the biggest path we will have read from the filesystem. But
this can happen if:

- the compiled-in PATH_MAX does not accurately reflect
what the filesystem is capable of

- the leading prefix is not _quite_ what is on disk; it
contains the next element from the name we are checking.
So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb"
exists, the prefix of interest is "aaa/bbb/ccc". If
"aaa/bbb" approaches PATH_MAX, then "ccc" can overflow
it.

So this can be triggered, but it's hard to do. In
particular, you cannot just "git clone" a bogus repo. The
verify_absent checks happen before unpack-trees writes
anything to the filesystem, so there are never any leading
prefixes during the initial checkout, and the bug doesn't
trigger. And by definition, these files are larger than
PATH_MAX, so writing them will fail, and clone will
complain (though it may write a partial path, which will
cause a subsequent "git checkout" to hit the bug).

We can fix it by creating the temporary path on the heap.
The extra malloc overhead is not important, as we are
already making at least one stat() call (and probably more
for the prefix discovery).

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

Merge branch 'ee/clean-test-fixes' into maintJunio C Hamano Fri, 4 Sep 2015 02:18:05 +0000 (19:18 -0700)

Merge branch 'ee/clean-test-fixes' into maint

* ee/clean-test-fixes:
t7300: fix broken && chains

Merge branch 'jk/log-missing-default-HEAD' into maintJunio C Hamano Fri, 4 Sep 2015 02:18:03 +0000 (19:18 -0700)

Merge branch 'jk/log-missing-default-HEAD' into maint

"git init empty && git -C empty log" said "bad default revision 'HEAD'",
which was found to be a bit confusing to new users.

* jk/log-missing-default-HEAD:
log: diagnose empty HEAD more clearly

Merge branch 'cc/trailers-corner-case-fix' into maintJunio C Hamano Fri, 4 Sep 2015 02:18:03 +0000 (19:18 -0700)

Merge branch 'cc/trailers-corner-case-fix' into maint

The "interpret-trailers" helper mistook a multi-paragraph title of
a commit log message with a colon in it as the end of the trailer
block.

* cc/trailers-corner-case-fix:
trailer: support multiline title
trailer: retitle a test and correct an in-comment message
trailer: ignore first line of message

Merge branch 'dt/commit-preserve-base-index-upon-opport... Junio C Hamano Fri, 4 Sep 2015 02:18:02 +0000 (19:18 -0700)

Merge branch 'dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update' into maint

When re-priming the cache-tree opportunistically while committing
the in-core index as-is, we mistakenly invalidated the in-core
index too aggressively, causing the experimental split-index code
to unnecessarily rewrite the on-disk index file(s).

* dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update:
commit: don't rewrite shared index unnecessarily

Merge branch 'rs/archive-zip-many' into maintJunio C Hamano Fri, 4 Sep 2015 02:18:01 +0000 (19:18 -0700)

Merge branch 'rs/archive-zip-many' into maint

"git archive" did not use zip64 extension when creating an archive
with more than 64k entries, which nobody should need, right ;-)?

* rs/archive-zip-many:
archive-zip: support more than 65535 entries
archive-zip: use a local variable to store the creator version
t5004: test ZIP archives with many entries

Merge branch 'jc/calloc-pathspec' into maintJunio C Hamano Fri, 4 Sep 2015 02:18:00 +0000 (19:18 -0700)

Merge branch 'jc/calloc-pathspec' into maint

Minor code cleanup.

* jc/calloc-pathspec:
ps_matched: xcalloc() takes nmemb and then element size

Merge branch 'ss/fix-config-fd-leak' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:59 +0000 (19:17 -0700)

Merge branch 'ss/fix-config-fd-leak' into maint

* ss/fix-config-fd-leak:
config: close config file handle in case of error

Merge branch 'sg/wt-status-header-inclusion' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:57 +0000 (19:17 -0700)

Merge branch 'sg/wt-status-header-inclusion' into maint

* sg/wt-status-header-inclusion:
wt-status: move #include "pathspec.h" to the header

Merge branch 'po/po-readme' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:56 +0000 (19:17 -0700)

Merge branch 'po/po-readme' into maint

Doc updates for i18n.

* po/po-readme:
po/README: Update directions for l10n contributors

Merge branch 'sg/t3020-typofix' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:54 +0000 (19:17 -0700)

Merge branch 'sg/t3020-typofix' into maint

* sg/t3020-typofix:
t3020: fix typo in test description

Merge branch 'as/docfix-reflog-expire-unreachable'... Junio C Hamano Fri, 4 Sep 2015 02:17:53 +0000 (19:17 -0700)

Merge branch 'as/docfix-reflog-expire-unreachable' into maint

Docfix.

* as/docfix-reflog-expire-unreachable:
Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable

Merge branch 'nd/fixup-linked-gitdir' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:53 +0000 (19:17 -0700)

Merge branch 'nd/fixup-linked-gitdir' into maint

The code in "multiple-worktree" support that attempted to recover
from an inconsistent state updated an incorrect file.

* nd/fixup-linked-gitdir:
setup: update the right file in multiple checkouts

Merge branch 'jk/rev-list-has-no-notes' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:52 +0000 (19:17 -0700)

Merge branch 'jk/rev-list-has-no-notes' into maint

"git rev-list" does not take "--notes" option, but did not complain
when one is given.

* jk/rev-list-has-no-notes:
rev-list: make it obvious that we do not support notes

Merge branch 'jk/fix-alias-pager-config-key-warnings... Junio C Hamano Fri, 4 Sep 2015 02:17:52 +0000 (19:17 -0700)

Merge branch 'jk/fix-alias-pager-config-key-warnings' into maint

Because the configuration system does not allow "alias.0foo" and
"pager.0foo" as the configuration key, the user cannot use '0foo'
as a custom command name anyway, but "git 0foo" tried to look these
keys up and emitted useless warnings before saying '0foo is not a
git command'. These warning messages have been squelched.

* jk/fix-alias-pager-config-key-warnings:
config: silence warnings for command names with invalid keys

Merge branch 'nd/dwim-wildcards-as-pathspecs' into... Junio C Hamano Fri, 4 Sep 2015 02:17:51 +0000 (19:17 -0700)

Merge branch 'nd/dwim-wildcards-as-pathspecs' into maint

Test updates for Windows.

* nd/dwim-wildcards-as-pathspecs:
t2019: skip test requiring '*' in a file name non Windows

Merge branch 'sg/help-group' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:51 +0000 (19:17 -0700)

Merge branch 'sg/help-group' into maint

We rewrote one of the build scripts in Perl but this reimplements
in Bourne shell.

* sg/help-group:
generate-cmdlist: re-implement as shell script

Merge branch 'ps/t1509-chroot-test-fixup' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:50 +0000 (19:17 -0700)

Merge branch 'ps/t1509-chroot-test-fixup' into maint

t1509 test that requires a dedicated VM environment had some
bitrot, which has been corrected.

* ps/t1509-chroot-test-fixup:
tests: fix cleanup after tests in t1509-root-worktree
tests: fix broken && chains in t1509-root-worktree

Merge branch 'jh/strbuf-read-use-read-in-full' into... Junio C Hamano Fri, 4 Sep 2015 02:17:50 +0000 (19:17 -0700)

Merge branch 'jh/strbuf-read-use-read-in-full' into maint

strbuf_read() used to have one extra iteration (and an unnecessary
strbuf_grow() of 8kB), which was eliminated.

* jh/strbuf-read-use-read-in-full:
strbuf_read(): skip unnecessary strbuf_grow() at eof

Merge branch 'jk/long-error-messages' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:49 +0000 (19:17 -0700)

Merge branch 'jk/long-error-messages' into maint

The codepath to produce error messages had a hard-coded limit to
the size of the message, primarily to avoid memory allocation while
calling die().

* jk/long-error-messages:
vreportf: avoid intermediate buffer
vreportf: report to arbitrary filehandles

Merge branch 'cb/open-noatime-clear-errno' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:49 +0000 (19:17 -0700)

Merge branch 'cb/open-noatime-clear-errno' into maint

When trying to see that an object does not exist, a state errno
leaked from our "first try to open a packfile with O_NOATIME and
then if it fails retry without it" logic on a system that refuses
O_NOATIME. This confused us and caused us to die, saying that the
packfile is unreadable, when we should have just reported that the
object does not exist in that packfile to the caller.

* cb/open-noatime-clear-errno:
git_open_noatime: return with errno=0 on success

Merge branch 'mh/get-remote-group-fix' into maintJunio C Hamano Fri, 4 Sep 2015 02:17:47 +0000 (19:17 -0700)

Merge branch 'mh/get-remote-group-fix' into maint

An off-by-one error made "git remote" to mishandle a remote with a
single letter nickname.

* mh/get-remote-group-fix:
get_remote_group(): use skip_prefix()
get_remote_group(): eliminate superfluous call to strcspn()
get_remote_group(): rename local variable "space" to "wordlen"
get_remote_group(): handle remotes with single-character names

trailer: support multiline titleChristian Couder Sun, 30 Aug 2015 19:14:40 +0000 (21:14 +0200)

trailer: support multiline title

We currently ignore the first line passed to `git interpret-trailers`,
when looking for the beginning of the trailers.

Unfortunately this does not work well when a commit is created with a
line break in the title, using for example the following command:

git commit -m 'place of
code: change we made'

That's why instead of ignoring only the first line, it is better to
ignore the first paragraph.

Signed-off-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7300: fix broken && chainsErik Elfström Sun, 30 Aug 2015 09:18:09 +0000 (11:18 +0200)

t7300: fix broken && chains

While we are here, remove some boilerplate by using test_commit.

Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log: diagnose empty HEAD more clearlyJeff King Sat, 29 Aug 2015 05:04:18 +0000 (01:04 -0400)

log: diagnose empty HEAD more clearly

If you init or clone an empty repository, the initial
message from running "git log" is not very friendly:

$ git init
Initialized empty Git repository in /home/peff/foo/.git/
$ git log
fatal: bad default revision 'HEAD'

Let's detect this situation and write a more friendly
message:

$ git log
fatal: your current branch 'master' does not have any commits yet

We also detect the case that 'HEAD' points to a broken ref;
this should be even less common, but is easy to see. Note
that we do not diagnose all possible cases. We rely on
resolve_ref, which means we do not get information about
complex cases. E.g., "--default master" would use dwim_ref
to find "refs/heads/master", but we notice only that
"master" does not exist. Similarly, a complex sha1
expression like "--default HEAD^2" will not resolve as a
ref.

But that's OK. We fall back to a generic error message in
those cases, and they are unlikely to be used anyway.
Catching an empty or broken "HEAD" improves the common case,
and the other cases are not regressed.

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

commit: don't rewrite shared index unnecessarilyDavid Turner Thu, 27 Aug 2015 17:07:54 +0000 (13:07 -0400)

commit: don't rewrite shared index unnecessarily

Remove a cache invalidation which would cause the shared index to be
rewritten on as-is commits.

When the cache-tree has changed, we need to update it. But we don't
necessarily need to update the shared index. So setting
active_cache_changed to SOMETHING_CHANGED is unnecessary. Instead, we
let update_main_cache_tree just update the CACHE_TREE_CHANGED bit.

In order to test this, make test-dump-split-index not segfault on
missing replace_bitmap/delete_bitmap. This new codepath is not called
now that the test passes, but is necessary to avoid a segfault when the
new test is run with the old builtin/commit.c code.

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

git-submodule: remove extraneous space from error messageAlex Henrie Thu, 27 Aug 2015 04:26:19 +0000 (22:26 -0600)

git-submodule: remove extraneous space from error message

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Acked-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.5.1 v2.5.1Junio C Hamano Fri, 28 Aug 2015 18:19:57 +0000 (11:19 -0700)

Git 2.5.1

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

Mingw: verify both ends of the pipe () callJose F. Morales Fri, 28 Aug 2015 09:43:37 +0000 (09:43 +0000)

Mingw: verify both ends of the pipe () call

The code to open and test the second end of the pipe clearly imitates
the code for the first end. A little too closely, though... Let's fix
the obvious copy-edit bug.

Signed-off-by: Jose F. Morales <jfmcjf@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive-zip: support more than 65535 entriesRené Scharfe Sat, 22 Aug 2015 19:06:45 +0000 (21:06 +0200)

archive-zip: support more than 65535 entries

Support more than 65535 entries cleanly by writing a "zip64 end of
central directory record" (with a 64-bit field for the number of
entries) before the usual "end of central directory record" (which
contains only a 16-bit field). InfoZIP's zip does the same.
Archives with 65535 or less entries are not affected.

Programs that extract all files like InfoZIP's zip and 7-Zip
ignored the field and could extract all files already. Software
that relies on the ZIP file directory to show a list of contained
files quickly to simulate to normal directory like Windows'
built-in ZIP functionality only saw a subset of the included files.

Windows supports ZIP64 since Vista according to
https://en.wikipedia.org/wiki/Zip_%28file_format%29#ZIP64.

Suggested-by: Johannes Schauer <josch@debian.org>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive-zip: use a local variable to store the creator... René Scharfe Sat, 22 Aug 2015 19:06:31 +0000 (21:06 +0200)

archive-zip: use a local variable to store the creator version

Use a simpler conditional right next to the code which makes a higher
creator version necessary -- namely symlink handling and support for
executable files -- instead of a long line with a ternary operator.
The resulting code has more lines but is simpler and allows reuse of
the value easily.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5004: test ZIP archives with many entriesRené Scharfe Sat, 22 Aug 2015 19:06:12 +0000 (21:06 +0200)

t5004: test ZIP archives with many entries

A ZIP file directory has a 16-bit field for the number of entries it
contains. There are 64-bit extensions to deal with that. Demonstrate
that git archive --format=zip currently doesn't use them and instead
overflows the field.

InfoZIP's unzip doesn't care about this field and extracts all files
anyway. Software that uses the directory for presenting a filesystem
like view quickly -- notably Windows -- depends on it, but doesn't
lend itself to an automatic test case easily. Use InfoZIP's zipinfo,
which probably isn't available everywhere but at least can provides
*some* way to check this field.

To speed things up a bit create and commit only a subset of the files
and build a fake tree out of duplicates and pass that to git archive.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trailer: retitle a test and correct an in-comment messageChristian Couder Wed, 26 Aug 2015 02:51:00 +0000 (04:51 +0200)

trailer: retitle a test and correct an in-comment message

Signed-off-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn doc: mention "svn-remote.<name>.include-paths"Brett Randall Mon, 24 Aug 2015 00:23:45 +0000 (10:23 +1000)

git-svn doc: mention "svn-remote.<name>.include-paths"

Mention the configuration variable in a way similar to how
"svn-remote.<name>.ignore-paths" is mentioned.

Signed-off-by: Brett Randall <javabrett@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/guess-repo-name-regression-fix' into... Junio C Hamano Tue, 25 Aug 2015 23:09:17 +0000 (16:09 -0700)

Merge branch 'jk/guess-repo-name-regression-fix' into maint

"git clone $URL" in recent releases of Git contains a regression in
the code that invents a new repository name incorrectly based on
the $URL. This has been corrected.

* jk/guess-repo-name-regression-fix:
clone: use computed length in guess_dir_name
clone: add tests for output directory

Merge branch 'jk/test-with-x' into maintJunio C Hamano Tue, 25 Aug 2015 23:09:16 +0000 (16:09 -0700)

Merge branch 'jk/test-with-x' into maint

Running tests with the "-x" option to make them verbose had some
unpleasant interactions with other features of the test suite.

* jk/test-with-x:
test-lib: disable trace when test is not verbose
test-lib: turn off "-x" tracing during chain-lint check

Merge branch 'sb/check-return-from-read-ref' into maintJunio C Hamano Tue, 25 Aug 2015 23:09:16 +0000 (16:09 -0700)

Merge branch 'sb/check-return-from-read-ref' into maint

* sb/check-return-from-read-ref:
transport-helper: die on errors reading refs.

Merge branch 'mm/pull-upload-pack' into maintJunio C Hamano Tue, 25 Aug 2015 23:09:15 +0000 (16:09 -0700)

Merge branch 'mm/pull-upload-pack' into maint

"git pull" in recent releases of Git has a regression in the code
that allows custom path to the --upload-pack=<program>. This has
been corrected.

Note that this is irrelevant for 'master' with "git pull" rewritten
in C.

* mm/pull-upload-pack:
pull: pass upload_pack only when it was given
pull.sh: quote $upload_pack when passing it to git-fetch

pull: pass upload_pack only when it was givenJunio C Hamano Tue, 25 Aug 2015 23:06:53 +0000 (16:06 -0700)

pull: pass upload_pack only when it was given

The upload_pack shell variable is initialized to an empty string, so
conditional expansion with ${upload_pack+"$upload_pack"} would not
work very well. You need a colon there.

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

generate-cmdlist: re-implement as shell scriptEric Sunshine Sun, 23 Aug 2015 21:31:09 +0000 (17:31 -0400)

generate-cmdlist: re-implement as shell script

527ec39 (generate-cmdlist: parse common group commands, 2015-05-21)
replaced generate-cmdlist.sh with a more functional Perl version,
generate-cmdlist.perl. The Perl version gleans named tags from a new
"common groups" section in command-list.txt and recognizes those
tags in "command list" section entries in place of the old 'common'
tag. This allows git-help to, not only recognize, but also group
common commands.

Although the tests require Perl, 527ec39 creates an unconditional
dependence upon Perl in the build system itself, which can not be
overridden with NO_PERL. Such a dependency may be undesirable; for
instance, the 'git-lite' package in the FreeBSD ports tree is
intended as a minimal Git installation (which may, for example, be
useful on servers needing only local clone and update capability),
which, historically, has not depended upon Perl[1].

Therefore, revive generate-cmdlist.sh and extend it to recognize
"common groups" and its named tags. Retire generate-cmdlist.perl.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/275905/focus=276132

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

setup: update the right file in multiple checkoutsNguyễn Thái Ngọc Duy Tue, 25 Aug 2015 10:30:46 +0000 (17:30 +0700)

setup: update the right file in multiple checkouts

This code is introduced in 23af91d (prune: strategies for linked
checkouts - 2014-11-30), and it's supposed to implement this rule from
that commit's message:

- linked checkouts are supposed to keep its location in $R/gitdir up
to date. The use case is auto fixup after a manual checkout move.

Note the name, "$R/gitdir", not "$R/gitfile". Correct the path to be
updated accordingly.

While at there, make sure I/O errors are not silently dropped.

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

rev-list: make it obvious that we do not support notesJeff King Sun, 23 Aug 2015 17:56:40 +0000 (13:56 -0400)

rev-list: make it obvious that we do not support notes

The rev-list command does not have the internal
infrastructure to display notes. Running:

git rev-list --notes HEAD

will silently ignore the "--notes" option. Running:

git rev-list --notes --grep=. HEAD

will crash on an assert. Running:

git rev-list --format=%N HEAD

will place a literal "%N" in the output (it does not even
expand to an empty string).

Let's have rev-list tell the user that it cannot fill the
user's request, rather than silently producing wrong data.
Likewise, let's remove mention of the notes options from the
rev-list documentation.

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

config: silence warnings for command names with invalid... Jeff King Mon, 24 Aug 2015 06:11:33 +0000 (02:11 -0400)

config: silence warnings for command names with invalid keys

When we are running the git command "foo", we may have to
look up the config keys "pager.foo" and "alias.foo". These
config schemes are mis-designed, as the command names can be
anything, but the config syntax has some restrictions. For
example:

$ git foo_bar
error: invalid key: pager.foo_bar
error: invalid key: alias.foo_bar
git: 'foo_bar' is not a git command. See 'git --help'.

You cannot name an alias with an underscore. And if you have
an external command with one, you cannot configure its
pager.

In the long run, we may develop a different config scheme
for these features. But in the near term (and because we'll
need to support the existing scheme indefinitely), we should
at least squelch the error messages shown above.

These errors come from git_config_parse_key. Ideally we
would pass a "quiet" flag to the config machinery, but there
are many layers between the pager code and the key parsing.
Passing a flag through all of those would be an invasive
change.

Instead, let's provide a config function to report on
whether a key is syntactically valid, and have the pager and
alias code skip lookup for bogus keys. We can build this
easily around the existing git_config_parse_key, with two
minor modifications:

1. We now handle a NULL store_key, to validate but not
write out the normalized key.

2. We accept a "quiet" flag to avoid writing to stderr.
This doesn't need to be a full-blown public "flags"
field, because we can make the existing implementation
a static helper function, keeping the mess contained
inside config.c.

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

wt-status: move #include "pathspec.h" to the headerSZEDER Gábor Thu, 20 Aug 2015 14:06:27 +0000 (16:06 +0200)

wt-status: move #include "pathspec.h" to the header

The declaration of 'struct wt_status' requires the declararion of 'struct
pathspec'.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trailer: ignore first line of messageChristian Couder Thu, 20 Aug 2015 21:59:15 +0000 (23:59 +0200)

trailer: ignore first line of message

When looking for the start of the trailers in the message
we are passed, we should ignore the first line of the message.

The reason is that if we are passed a patch or commit message
then the first line should be the patch title.
If we are passed only trailers we can expect that they start
with an empty line that can be ignored too.

This way we can properly process commit messages that have
only one line with something that looks like a trailer, for
example like "area of code: change we made".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/config: fix inconsistent label on gc... Andreas Schwab Fri, 21 Aug 2015 15:06:18 +0000 (17:06 +0200)

Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable

Change <ref> to <pattern> in the description of
gc.*.reflogExpireUnreachable, since that is what the text refers to.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3020: fix typo in test descriptionSZEDER Gábor Thu, 20 Aug 2015 13:58:55 +0000 (15:58 +0200)

t3020: fix typo in test description

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ps_matched: xcalloc() takes nmemb and then element... Junio C Hamano Thu, 20 Aug 2015 16:57:32 +0000 (09:57 -0700)

ps_matched: xcalloc() takes nmemb and then element size

Even though multiplication is commutative, the order of arguments
should be xcalloc(nmemb, size). ps_matched is an array of 1-byte
element whose size is the same as the number of pathspec elements.

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

Start preparing for 2.5.1Junio C Hamano Wed, 19 Aug 2015 21:26:31 +0000 (14:26 -0700)

Start preparing for 2.5.1

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

Merge branch 'ta/docfix-index-format-tech' into maintJunio C Hamano Wed, 19 Aug 2015 21:41:34 +0000 (14:41 -0700)

Merge branch 'ta/docfix-index-format-tech' into maint

* ta/docfix-index-format-tech:
typofix for index-format.txt

Merge branch 'sb/parse-options-codeformat' into maintJunio C Hamano Wed, 19 Aug 2015 21:41:33 +0000 (14:41 -0700)

Merge branch 'sb/parse-options-codeformat' into maint

* sb/parse-options-codeformat:
parse-options: align curly braces for all options

Merge branch 'sb/remove-unused-var-from-builtin-add... Junio C Hamano Wed, 19 Aug 2015 21:41:33 +0000 (14:41 -0700)

Merge branch 'sb/remove-unused-var-from-builtin-add' into maint

* sb/remove-unused-var-from-builtin-add:
add: remove dead code

Merge branch 'kn/tag-doc-fix' into maintJunio C Hamano Wed, 19 Aug 2015 21:41:32 +0000 (14:41 -0700)

Merge branch 'kn/tag-doc-fix' into maint

* kn/tag-doc-fix:
Documentation/tag: remove double occurance of "<pattern>"

Merge branch 'es/doc-clean-outdated-tools' into maintJunio C Hamano Wed, 19 Aug 2015 21:41:31 +0000 (14:41 -0700)

Merge branch 'es/doc-clean-outdated-tools' into maint

* es/doc-clean-outdated-tools:
Documentation/git-tools: retire manually-maintained list
Documentation/git-tools: drop references to defunct tools
Documentation/git-tools: fix item text formatting
Documentation/git-tools: improve discoverability of Git wiki
Documentation/git: drop outdated Cogito reference

Merge branch 'nd/export-worktree' into maintJunio C Hamano Wed, 19 Aug 2015 21:41:30 +0000 (14:41 -0700)

Merge branch 'nd/export-worktree' into maint

Running an aliased command from a subdirectory when the .git thing
in the working tree is a gitfile pointing elsewhere did not work.

* nd/export-worktree:
setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR

Merge branch 'mh/fast-import-optimize-current-from... Junio C Hamano Wed, 19 Aug 2015 21:41:29 +0000 (14:41 -0700)

Merge branch 'mh/fast-import-optimize-current-from' into maint

Often a fast-import stream builds a new commit on top of the
previous commit it built, and it often unconditionally emits a
"from" command to specify the first parent, which can be omitted in
such a case. This caused fast-import to forget the tree of the
previous commit and then re-read it from scratch, which was
inefficient. Optimize for this common case.

* mh/fast-import-optimize-current-from:
fast-import: do less work when given "from" matches current branch head

Merge branch 'ib/scripted-parse-opt-better-hint-string... Junio C Hamano Wed, 19 Aug 2015 21:41:29 +0000 (14:41 -0700)

Merge branch 'ib/scripted-parse-opt-better-hint-string' into maint

The "rev-parse --parseopt" mode parsed the option specification
and the argument hint in a strange way to allow '=' and other
special characters in the option name while forbidding them from
the argument hint. This made it impossible to define an option
like "--pair <key>=<value>" with "pair=key=value" specification,
which instead would have defined a "--pair=key <value>" option.

* ib/scripted-parse-opt-better-hint-string:
rev-parse --parseopt: allow [*=?!] in argument hints