4 years agoGit 2.4.12 v2.4.12
Junio C Hamano [Fri, 5 May 2017 03:25:09 +0000 (12:25 +0900)]
Git 2.4.12

Signed-off-by: Junio C Hamano <>
4 years agoMerge branch 'jk/shell-no-repository-that-begins-with-dash' into maint-2.4
Junio C Hamano [Fri, 5 May 2017 03:17:55 +0000 (12:17 +0900)]
Merge branch 'jk/shell-no-repository-that-begins-with-dash' into maint-2.4

* jk/shell-no-repository-that-begins-with-dash:
  shell: disallow repo names beginning with dash

4 years agoshell: disallow repo names beginning with dash
Jeff King [Sat, 29 Apr 2017 12:36:44 +0000 (08:36 -0400)]
shell: disallow repo names beginning with dash

When a remote server uses git-shell, the client side will
connect to it like:

  ssh server "git-upload-pack 'foo.git'"

and we literally exec ("git-upload-pack", "foo.git"). In
early versions of upload-pack and receive-pack, we took a
repository argument and nothing else. But over time they
learned to accept dashed options. If the user passes a
repository name that starts with a dash, the results are
confusing at best (we complain of a bogus option instead of
a non-existent repository) and malicious at worst (the user
can start an interactive pager via "--help").

We could pass "--" to the sub-process to make sure the
user's argument is interpreted as a branch name. I.e.:

  git-upload-pack -- -foo.git

But adding "--" automatically would make us inconsistent
with a normal shell (i.e., when git-shell is not in use),
where "-foo.git" would still be an error. For that case, the
client would have to specify the "--", but they can't do so
reliably, as existing versions of git-shell do not allow
more than a single argument.

The simplest thing is to simply disallow "-" at the start of
the repo name argument. This hasn't worked either with or
without git-shell since version 1.0.0, and nobody has

Note that this patch just applies to do_generic_cmd(), which
runs upload-pack, receive-pack, and upload-archive. There
are two other types of commands that git-shell runs:

  - do_cvs_cmd(), but this already restricts the argument to
    be the literal string "server"

  - admin-provided commands in the git-shell-commands
    directory. We'll pass along arbitrary arguments there,
    so these commands could have similar problems. But these
    commands might actually understand dashed arguments, so
    we cannot just block them here. It's up to the writer of
    the commands to make sure they are safe. With great
    power comes great responsibility.

Reported-by: Timo Schmid <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoGit 2.4.11 v2.4.11
Junio C Hamano [Thu, 17 Mar 2016 17:00:44 +0000 (10:00 -0700)]
Git 2.4.11

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/path-name-safety-2.4' into maint-2.4
Junio C Hamano [Thu, 17 Mar 2016 16:55:54 +0000 (09:55 -0700)]
Merge branch 'jk/path-name-safety-2.4' into maint-2.4

Bugfix patches were backported from the 'master' front to plug heap
corruption holes, to catch integer overflow in the computation of
pathname lengths, and to get rid of the name_path API.  Both of
these would have resulted in writing over an under-allocated buffer
when formulating pathnames while tree traversal.

* jk/path-name-safety-2.4:
  list-objects: pass full pathname to callbacks
  list-objects: drop name_path entirely
  list-objects: convert name_path to a strbuf
  show_object_with_name: simplify by using path_name()
  http-push: stop using name_path
  tree-diff: catch integer overflow in combine_diff_path allocation
  add helpers for detecting size_t overflow

5 years agolist-objects: pass full pathname to callbacks
Jeff King [Thu, 11 Feb 2016 22:28:36 +0000 (17:28 -0500)]
list-objects: pass full pathname to callbacks

When we find a blob at "a/b/c", we currently pass this to
our show_object_fn callbacks as two components: "a/b/" and
"c". Callbacks which want the full value then call
path_name(), which concatenates the two. But this is an
inefficient interface; the path is a strbuf, and we could
simply append "c" to it temporarily, then roll back the
length, without creating a new copy.

So we could improve this by teaching the callsites of
path_name() this trick (and there are only 3). But we can
also notice that no callback actually cares about the
broken-down representation, and simply pass each callback
the full path "a/b/c" as a string. The callback code becomes
even simpler, then, as we do not have to worry about freeing
an allocated buffer, nor rolling back our modification to
the strbuf.

This is theoretically less efficient, as some callbacks
would not bother to format the final path component. But in
practice this is not measurable. Since we use the same
strbuf over and over, our work to grow it is amortized, and
we really only pay to memcpy a few bytes.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agolist-objects: drop name_path entirely
Jeff King [Thu, 11 Feb 2016 22:26:44 +0000 (17:26 -0500)]
list-objects: drop name_path entirely

In the previous commit, we left name_path as a thin wrapper
around a strbuf. This patch drops it entirely. As a result,
every show_object_fn callback needs to be adjusted. However,
none of their code needs to be changed at all, because the
only use was to pass it to path_name(), which now handles
the bare strbuf.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agolist-objects: convert name_path to a strbuf
Jeff King [Thu, 11 Feb 2016 22:26:18 +0000 (17:26 -0500)]
list-objects: convert name_path to a strbuf

The "struct name_path" data is examined in only two places:
we generate it in process_tree(), and we convert it to a
single string in path_name(). Everyone else just passes it
through to those functions.

We can further note that process_tree() already keeps a
single strbuf with the leading tree path, for use with

Instead of building a separate name_path linked list, let's
just use the one we already build in "base". This reduces
the amount of code (especially tricky code in path_name()
which did not check for integer overflows caused by deep
or large pathnames).

It is also more efficient in some instances.  Any time we
were using tree_entry_interesting, we were building up the
strbuf anyway, so this is an immediate and obvious win
there. In cases where we were not, we trade off storing
"pathname/" in a strbuf on the heap for each level of the
path, instead of two pointers and an int on the stack (with
one pointer into the tree object). On a 64-bit system, the
latter is 20 bytes; so if path components are less than that
on average, this has lower peak memory usage.  In practice
it probably doesn't matter either way; we are already
holding in memory all of the tree objects leading up to each
pathname, and for normal-depth pathnames, we are only
talking about hundreds of bytes.

This patch leaves "struct name_path" as a thin wrapper
around the strbuf, to avoid disrupting callbacks. We should
fix them, but leaving it out makes this diff easier to view.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoshow_object_with_name: simplify by using path_name()
Jeff King [Thu, 11 Feb 2016 22:24:18 +0000 (17:24 -0500)]
show_object_with_name: simplify by using path_name()

When "git rev-list" shows an object with its associated path
name, it does so by walking the name_path linked list and
printing each component (stopping at any embedded NULs or

We'd like to eventually get rid of name_path entirely in
favor of a single buffer, and dropping this custom printing
code is part of that. As a first step, let's use path_name()
to format the list into a single buffer, and print that.
This is strictly less efficient than the original, but it's
a temporary step in the refactoring; our end game will be to
get the fully formatted name in the first place.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agohttp-push: stop using name_path
Jeff King [Thu, 11 Feb 2016 22:23:48 +0000 (17:23 -0500)]
http-push: stop using name_path

The graph traversal code here passes along a name_path to
build up the pathname at which we find each blob. But we
never actually do anything with the resulting names, making
it a waste of code and memory.

This usage came in aa1dbc9 (Update http-push functionality,
2006-03-07), and originally the result was passed to
"add_object" (which stored it, but didn't really use it,
either). But we stopped using that function in 1f1e895 (Add
"named object array" concept, 2006-06-19) in favor of
storing just the objects themselves.

Moreover, the generation of the name in process_tree() is
buggy. It sticks "name" onto the end of the name_path linked
list, and then passes it down again as it recurses (instead
of "entry.path"). So it's a good thing this was unused, as
the resulting path for "a/b/c/d" would end up as "a/a/a/a".

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agotree-diff: catch integer overflow in combine_diff_path allocation
Jeff King [Fri, 19 Feb 2016 11:21:30 +0000 (06:21 -0500)]
tree-diff: catch integer overflow in combine_diff_path allocation

A combine_diff_path struct has two "flex" members allocated
alongside the struct: a string to hold the pathname, and an
array of parent pointers. We use an "int" to compute this,
meaning we may easily overflow it if the pathname is
extremely long.

We can fix this by using size_t, and checking for overflow
with the st_add helper.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoadd helpers for detecting size_t overflow
Jeff King [Fri, 19 Feb 2016 11:21:19 +0000 (06:21 -0500)]
add helpers for detecting size_t overflow

Performing computations on size_t variables that we feed to
xmalloc and friends can be dangerous, as an integer overflow
can cause us to allocate a much smaller chunk than we

We already have unsigned_add_overflows(), but let's add
unsigned_mult_overflows() to that. Furthermore, rather than
have each site manually check and die on overflow, we can
provide some helpers that will:

  - promote the arguments to size_t, so that we know we are
    doing our computation in the same size of integer that
    will ultimately be fed to xmalloc

  - check and die on overflow

  - return the result so that computations can be done in
    the parameter list of xmalloc.

These functions are a lot uglier to use than normal
arithmetic operators (you have to do "st_add(foo, bar)"
instead of "foo + bar"). To at least limit the damage, we
also provide multi-valued versions. So rather than:

  st_add(st_add(a, b), st_add(c, d));

you can write:

  st_add4(a, b, c, d);

This isn't nearly as elegant as a varargs function, but it's
a lot harder to get it wrong. You don't have to remember to
add a sentinel value at the end, and the compiler will
complain if you get the number of arguments wrong. This
patch adds only the numbered variants required to convert
the current code base; we can easily add more later if

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoGit 2.4.10 v2.4.10
Junio C Hamano [Mon, 28 Sep 2015 22:29:54 +0000 (15:29 -0700)]
Git 2.4.10

Signed-off-by: Junio C Hamano <>
5 years agoSync with 2.3.10
Junio C Hamano [Mon, 28 Sep 2015 22:28:26 +0000 (15:28 -0700)]
Sync with 2.3.10

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

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/xdiff-memory-limits' into maint-2.3
Junio C Hamano [Mon, 28 Sep 2015 21:59:28 +0000 (14:59 -0700)]
Merge branch 'jk/xdiff-memory-limits' into maint-2.3

5 years agomerge-file: enforce MAX_XDIFF_SIZE on incoming files
Jeff 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.,

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 <>
Signed-off-by: Junio C Hamano <>
5 years agoxdiff: reject files larger than ~1GB
Jeff 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

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoreact to errors in xdi_diff
Jeff 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

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/transfer-limit-redirection' into maint-2.3
Junio C Hamano [Mon, 28 Sep 2015 21:46:05 +0000 (14:46 -0700)]
Merge branch 'jk/transfer-limit-redirection' into maint-2.3

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

5 years agohttp: limit redirection depth
Blake 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 <>
Signed-off-by: Junio C Hamano <>
5 years agohttp: limit redirection to protocol-whitelist
Blake 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 <>
Signed-off-by: Junio C Hamano <>
5 years agotransport: refactor protocol whitelist code
Jeff 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 <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agosubmodule: allow only certain protocols for submodule fetches
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 <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agotransport: add a protocol-whitelist environment variable
Jeff 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

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoGit 2.4.9 v2.4.9
Junio C Hamano [Fri, 4 Sep 2015 17:36:00 +0000 (10:36 -0700)]
Git 2.4.9

Signed-off-by: Junio C Hamano <>
5 years agoSync with 2.3.9
Junio C Hamano [Fri, 4 Sep 2015 17:34:19 +0000 (10:34 -0700)]
Sync with 2.3.9

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

Signed-off-by: Junio C Hamano <>
5 years agoSync with 2.2.3
Junio C Hamano [Fri, 4 Sep 2015 17:29:28 +0000 (10:29 -0700)]
Sync with 2.2.3

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

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/long-paths' into maint-2.2
Junio C Hamano [Fri, 4 Sep 2015 17:25:23 +0000 (10:25 -0700)]
Merge branch 'jk/long-paths' into maint-2.2

5 years agoshow-branch: use a strbuf for reflog descriptions
Jeff 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 <>
Signed-off-by: Junio C Hamano <>
5 years agoread_info_alternates: handle paths larger than PATH_MAX
Jeff 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 <>
Signed-off-by: Junio C Hamano <>
5 years agonotes: use a strbuf in add_non_note
Jeff 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 <>
Signed-off-by: Junio C Hamano <>
5 years agoverify_absent: allow filenames longer than PATH_MAX
Jeff 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

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

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 <>
Signed-off-by: Junio C Hamano <>
5 years agoGit 2.4.8 v2.4.8
Junio C Hamano [Mon, 3 Aug 2015 17:40:37 +0000 (10:40 -0700)]
Git 2.4.8

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'js/rebase-i-clean-up-upon-continue-to-skip' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:34 +0000 (10:41 -0700)]
Merge branch 'js/rebase-i-clean-up-upon-continue-to-skip' into maint

Abandoning an already applied change in "git rebase -i" with
"--continue" left CHERRY_PICK_HEAD and confused later steps.

* js/rebase-i-clean-up-upon-continue-to-skip:
  rebase -i: do not leave a CHERRY_PICK_HEAD file behind
  t3404: demonstrate CHERRY_PICK_HEAD bug

5 years agoMerge branch 'ss/clone-guess-dir-name-simplify' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:33 +0000 (10:41 -0700)]
Merge branch 'ss/clone-guess-dir-name-simplify' into maint

Code simplification.

* ss/clone-guess-dir-name-simplify:
  clone: simplify string handling in guess_dir_name()

5 years agoMerge branch 'sg/completion-commit-cleanup' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:33 +0000 (10:41 -0700)]
Merge branch 'sg/completion-commit-cleanup' into maint

* sg/completion-commit-cleanup:
  completion: teach 'scissors' mode to 'git commit --cleanup='

5 years agoMerge branch 'pt/am-abort-fix' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:32 +0000 (10:41 -0700)]
Merge branch 'pt/am-abort-fix' into maint

Various fixes around "git am" that applies a patch to a history
that is not there yet.

* pt/am-abort-fix:
  am --abort: keep unrelated commits on unborn branch
  am --abort: support aborting to unborn branch
  am --abort: revert changes introduced by failed 3way merge
  am --skip: support skipping while on unborn branch
  am -3: support 3way merge on unborn branch
  am --skip: revert changes introduced by failed 3way merge

5 years agoMerge branch 'mh/reporting-broken-refs-from-for-each-ref' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:31 +0000 (10:41 -0700)]
Merge branch 'mh/reporting-broken-refs-from-for-each-ref' into maint

"git for-each-ref" reported "missing object" for 0{40} when it
encounters a broken ref.  The lack of object whose name is 0{40} is
not the problem; the ref being broken is.

* mh/reporting-broken-refs-from-for-each-ref:
  read_loose_refs(): treat NULL_SHA1 loose references as broken
  read_loose_refs(): simplify function logic
  for-each-ref: report broken references correctly
  t6301: new tests of for-each-ref error handling

5 years agoMerge branch 'sg/commit-cleanup-scissors' into maint
Junio C Hamano [Mon, 3 Aug 2015 17:41:30 +0000 (10:41 -0700)]
Merge branch 'sg/commit-cleanup-scissors' into maint

"git commit --cleanup=scissors" was not careful enough to protect
against getting fooled by a line that looked like scissors.

* sg/commit-cleanup-scissors:
  commit: cope with scissors lines in commit message

5 years agoGit 2.4.7 v2.4.7
Junio C Hamano [Mon, 27 Jul 2015 19:25:42 +0000 (12:25 -0700)]
Git 2.4.7

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/pretty-encoding-doc' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:48 +0000 (12:21 -0700)]
Merge branch 'jk/pretty-encoding-doc' into maint

Doc update.

* jk/pretty-encoding-doc:
  docs: clarify that --encoding can produce invalid sequences

5 years agoMerge branch 'tb/checkout-doc' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:47 +0000 (12:21 -0700)]
Merge branch 'tb/checkout-doc' into maint

Doc update.

* tb/checkout-doc:
  git-checkout.txt: document "git checkout <pathspec>" better

5 years agoMerge branch 'ls/hint-rev-list-count' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:47 +0000 (12:21 -0700)]
Merge branch 'ls/hint-rev-list-count' into maint

* ls/hint-rev-list-count:
  rev-list: add --count to usage guide

5 years agoMerge branch 'mm/branch-doc-updates' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:46 +0000 (12:21 -0700)]
Merge branch 'mm/branch-doc-updates' into maint

* mm/branch-doc-updates:
  Documentation/branch: document -M and -D in terms of --force
  Documentation/branch: document -d --force and -m --force

5 years agoMerge branch 'jc/fsck-retire-require-eoh' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:45 +0000 (12:21 -0700)]
Merge branch 'jc/fsck-retire-require-eoh' into maint

A fix to a minor regression to "git fsck" in v2.2 era that started
complaining about a body-less tag object when it lacks a separator
empty line after its header to separate it with a non-existent body.

* jc/fsck-retire-require-eoh:
  fsck: it is OK for a tag and a commit to lack the body

5 years agoMerge branch 'et/http-proxyauth' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:44 +0000 (12:21 -0700)]
Merge branch 'et/http-proxyauth' into maint

We used to ask libCURL to use the most secure authentication method
available when talking to an HTTP proxy only when we were told to
talk to one via configuration variables.  We now ask libCURL to
always use the most secure authentication method, because the user
can tell libCURL to use an HTTP proxy via an environment variable
without using configuration variables.

* et/http-proxyauth:
  http: always use any proxy auth method available

5 years agoMerge branch 'jc/unexport-git-pager-in-use-in-pager' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:43 +0000 (12:21 -0700)]
Merge branch 'jc/unexport-git-pager-in-use-in-pager' into maint

When you say "!<ENTER>" while running say "git log", you'd confuse
yourself in the resulting shell, that may look as if you took
control back to the original shell you spawned "git log" from but
that isn't what is happening.  To that new shell, we leaked
GIT_PAGER_IN_USE environment variable that was meant as a local
communication between the original "Git" and subprocesses that was
spawned by it after we launched the pager, which caused many
"interesting" things to happen, e.g. "git diff | cat" still paints
its output in color by default.

Stop leaking that environment variable to the pager's half of the
fork; we only need it on "Git" side when we spawn the pager.

* jc/unexport-git-pager-in-use-in-pager:
  pager: do not leak "GIT_PAGER_IN_USE" to the pager

5 years agoMerge branch 'mh/strbuf-read-file-returns-ssize-t' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:43 +0000 (12:21 -0700)]
Merge branch 'mh/strbuf-read-file-returns-ssize-t' into maint

Avoid possible ssize_t to int truncation.

* mh/strbuf-read-file-returns-ssize-t:
  strbuf: strbuf_read_file() should return ssize_t

5 years agoMerge branch 'kb/config-unmap-before-renaming' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:42 +0000 (12:21 -0700)]
Merge branch 'kb/config-unmap-before-renaming' into maint

"git config" failed to update the configuration file when the
underlying filesystem is incapable of renaming a file that is still

* kb/config-unmap-before-renaming:
  config.c: fix writing config files on Windows network shares

5 years agoMerge branch 'jk/rev-list-no-bitmap-while-pruning' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:42 +0000 (12:21 -0700)]
Merge branch 'jk/rev-list-no-bitmap-while-pruning' into maint

A minor bugfix when pack bitmap is used with "rev-list --count".

* jk/rev-list-no-bitmap-while-pruning:
  rev-list: disable --use-bitmap-index when pruning commits

5 years agoMerge branch 'rh/test-color-avoid-terminfo-in-original-home' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:41 +0000 (12:21 -0700)]
Merge branch 'rh/test-color-avoid-terminfo-in-original-home' into maint

An ancient test framework enhancement to allow color was not
entirely correct; this makes it work even when tput needs to read
from the ~/.terminfo under the user's real HOME directory.

* rh/test-color-avoid-terminfo-in-original-home: fix color support when tput needs ~/.terminfo
  Revert " do tests for color support after changing HOME"

5 years agoMerge branch 'jk/fix-refresh-utime' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:40 +0000 (12:21 -0700)]
Merge branch 'jk/fix-refresh-utime' into maint

Fix a small bug in our use of umask() return value.

* jk/fix-refresh-utime:
  check_and_freshen_file: fix reversed success-check

5 years agoMerge branch 'cb/rebase-am-exit-code' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:39 +0000 (12:21 -0700)]
Merge branch 'cb/rebase-am-exit-code' into maint

"git rebase" did not exit with failure when format-patch it invoked
failed for whatever reason.

* cb/rebase-am-exit-code:
  rebase: return non-zero error code if format-patch fails

5 years agoMerge branch 'jk/index-pack-reduce-recheck' into maint
Junio C Hamano [Mon, 27 Jul 2015 19:21:38 +0000 (12:21 -0700)]
Merge branch 'jk/index-pack-reduce-recheck' into maint

Disable "have we lost a race with competing repack?" check while
receiving a huge object transfer that runs index-pack.

* jk/index-pack-reduce-recheck:
  index-pack: avoid excessive re-reading of pack directory

5 years agoGit 2.4.6 v2.4.6
Junio C Hamano [Wed, 15 Jul 2015 18:45:42 +0000 (11:45 -0700)]
Git 2.4.6

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'mm/describe-doc' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:26 +0000 (11:41 -0700)]
Merge branch 'mm/describe-doc' into maint


* mm/describe-doc:
  Documentation/describe: improve one-line summary

5 years agoMerge branch 'jc/prompt-document-ps1-state-separator' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:26 +0000 (11:41 -0700)]
Merge branch 'jc/prompt-document-ps1-state-separator' into maint


* jc/prompt-document-ps1-state-separator: document GIT_PS1_STATESEPARATOR

5 years agoMerge branch 'es/osx-header-pollutes-mask-macro' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:24 +0000 (11:41 -0700)]
Merge branch 'es/osx-header-pollutes-mask-macro' into maint

* es/osx-header-pollutes-mask-macro:
  ewah: use less generic macro name
  ewah/bitmap: silence warning about MASK macro redefinition

5 years agoMerge branch 'es/utf8-stupid-compiler-workaround' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:23 +0000 (11:41 -0700)]
Merge branch 'es/utf8-stupid-compiler-workaround' into maint

A compilation workaround.

* es/utf8-stupid-compiler-workaround:
  utf8: NO_ICONV: silence uninitialized variable warning

5 years agoMerge branch 'fk/doc-format-patch-vn' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:22 +0000 (11:41 -0700)]
Merge branch 'fk/doc-format-patch-vn' into maint


* fk/doc-format-patch-vn:
  doc: format-patch: fix typo

5 years agoMerge branch 'pt/t0302-needs-sanity' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:21 +0000 (11:41 -0700)]
Merge branch 'pt/t0302-needs-sanity' into maint

* pt/t0302-needs-sanity:
  t0302: "unreadable" test needs SANITY prereq

5 years agoMerge branch 'me/fetch-into-shallow-safety' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:20 +0000 (11:41 -0700)]
Merge branch 'me/fetch-into-shallow-safety' into maint

"git fetch --depth=<depth>" and "git clone --depth=<depth>" issued
a shallow transfer request even to an upload-pack that does not
support the capability.

* me/fetch-into-shallow-safety:
  fetch-pack: check for shallow if depth given

5 years agoMerge branch 'mh/fsck-reflog-entries' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:19 +0000 (11:41 -0700)]
Merge branch 'mh/fsck-reflog-entries' into maint

"git fsck" used to ignore missing or invalid objects recorded in reflog.

* mh/fsck-reflog-entries:
  fsck: report errors if reflog entries point at invalid objects
  fsck_handle_reflog_sha1(): new function

5 years agoMerge branch 'af/tcsh-completion-noclobber' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:18 +0000 (11:41 -0700)]
Merge branch 'af/tcsh-completion-noclobber' into maint

The tcsh completion writes a bash scriptlet but that would have
failed for users with noclobber set.

* af/tcsh-completion-noclobber:
  git-completion.tcsh: fix redirect with noclobber

5 years agoMerge branch 'pa/auto-gc-mac-osx' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:17 +0000 (11:41 -0700)]
Merge branch 'pa/auto-gc-mac-osx' into maint

Recent Mac OS X updates breaks the logic to detect that the machine
is on the AC power in the sample pre-auto-gc script.

* pa/auto-gc-mac-osx:
  hooks/pre-auto-gc: adjust power checking for newer OS X

5 years agoMerge branch 'jc/do-not-feed-tags-to-clear-commit-marks' into maint
Junio C Hamano [Wed, 15 Jul 2015 18:41:16 +0000 (11:41 -0700)]
Merge branch 'jc/do-not-feed-tags-to-clear-commit-marks' into maint

"git format-patch --ignore-if-upstream A..B" did not like to be fed
tags as boundary commits.

* jc/do-not-feed-tags-to-clear-commit-marks:
  format-patch: do not feed tags to clear_commit_marks()

5 years agoclone: simplify string handling in guess_dir_name()
Sebastian Schuberth [Thu, 9 Jul 2015 18:24:08 +0000 (18:24 +0000)]
clone: simplify string handling in guess_dir_name()

Signed-off-by: Sebastian Schuberth <>
Signed-off-by: Junio C Hamano <>
5 years agocheck_and_freshen_file: fix reversed success-check
Jeff King [Wed, 8 Jul 2015 20:33:52 +0000 (16:33 -0400)]
check_and_freshen_file: fix reversed success-check

When we want to write out a loose object file, we have
always first made sure we don't already have the object
somewhere. Since 33d4221 (write_sha1_file: freshen existing
objects, 2014-10-15), we also update the timestamp on the
file, so that a simultaneous prune knows somebody is
likely to reference it soon.

If our utime() call fails, we treat this the same as not
having the object in the first place; the safe thing to do
is write out another copy. However, the loose-object check
accidentally inverts the utime() check; it returns failure
_only_ when the utime() call actually succeeded. Thus it was
failing to protect us there, and in the normal case where
utime() succeeds, it caused us to pointlessly write out and
link the object.

This passed our freshening tests, because writing out the
new object is certainly _one_ way of updating its utime. So
the normal case was inefficient, but not wrong.

While we're here, let's also drop a comment in front of the
check_and_freshen functions, making a note of their return
type (since it is not our usual "0 for success, -1 for

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agorebase: return non-zero error code if format-patch fails
Clemens Buchacher [Thu, 2 Jul 2015 09:11:33 +0000 (11:11 +0200)]
rebase: return non-zero error code if format-patch fails

Since e481af06 (rebase: Handle cases where format-patch fails) we
notice if format-patch fails and return immediately from
git-rebase--am. We save the return value with ret=$?, but then we
return $?, which is usually zero in this case.

Fix this by returning $ret instead.

Cc: Andrew Wong <>
Signed-off-by: Clemens Buchacher <>
Helped-by: Jorge Nunes <>
Signed-off-by: Junio C Hamano <>
5 years agoDocumentation/branch: document -M and -D in terms of --force
Matthieu Moy [Thu, 2 Jul 2015 14:07:21 +0000 (16:07 +0200)]
Documentation/branch: document -M and -D in terms of --force

Now that we have proper documentation for --force's interaction with -d
and -m, we can avoid duplication and consider -M and -D as convenience
aliases for -m --force and -d --force.

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
5 years agoDocumentation/branch: document -d --force and -m --force
Matthieu Moy [Thu, 2 Jul 2015 14:07:20 +0000 (16:07 +0200)]
Documentation/branch: document -d --force and -m --force

The --force option was modified in 356e91f (branch: allow -f with -m and
-d, 2014-12-08), but the documentation was not updated.

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
5 years agostrbuf: strbuf_read_file() should return ssize_t
Michael Haggerty [Fri, 3 Jul 2015 13:59:32 +0000 (15:59 +0200)]
strbuf: strbuf_read_file() should return ssize_t

It is currently declared to return int, which could overflow for
large files.

Signed-off-by: Michael Haggerty <>
Signed-off-by: Junio C Hamano <>
5 years agopager: do not leak "GIT_PAGER_IN_USE" to the pager
Junio C Hamano [Fri, 3 Jul 2015 17:18:45 +0000 (10:18 -0700)]
pager: do not leak "GIT_PAGER_IN_USE" to the pager

Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we
export GIT_PAGER_IN_USE so that a process that becomes the upstream
of the spawned pager can still tell that we have spawned the pager
and decide to do colored output even when its output no longer goes
to a terminal (i.e. isatty(1)).

But we forgot to clear it from the enviornment of the spawned pager.

This is not a problem in a sane world, but if you have a handful of
thousands Git users in your organization, somebody is bound to do
strange things, e.g. typing "!<ENTER>" instead of 'q' to get control
back from $LESS.  GIT_PAGER_IN_USE is still set in that subshell
spawned by "less", and all sorts of interesting things starts
happening, e.g. "git diff | cat" starts coloring its output.

We can clear the environment variable in the half of the fork that
runs the pager to avoid the confusion.

Signed-off-by: Junio C Hamano <>
Acked-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agorev-list: disable --use-bitmap-index when pruning commits
Jeff King [Wed, 1 Jul 2015 18:42:17 +0000 (14:42 -0400)]
rev-list: disable --use-bitmap-index when pruning commits

The reachability bitmaps do not have enough information to
tell us which commits might have changed path "foo", so the
current code produces wrong answers for:

  git rev-list --use-bitmap-index --count HEAD -- foo

(it silently ignores the "foo" limiter). Instead, we should
fall back to doing a normal traversal (it is OK to fall
back rather than complain, because --use-bitmap-index is a
pure optimization, and might not kick in for other reasons,
such as there being no bitmaps in the repository).

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agorev-list: add --count to usage guide
Lawrence Siebert [Wed, 1 Jul 2015 09:24:11 +0000 (02:24 -0700)]
rev-list: add --count to usage guide

--count should be mentioned in the usage guide, this updates code and

Signed-off-by: Lawrence Siebert <>
Signed-off-by: Junio C Hamano <>
5 years agoconfig.c: fix writing config files on Windows network shares
Karsten Blees [Tue, 30 Jun 2015 14:34:13 +0000 (16:34 +0200)]
config.c: fix writing config files on Windows network shares

Renaming to an existing file doesn't work on Windows network shares if the
target file is open.

munmap() the old config file before commit_lock_file.

Signed-off-by: Karsten Blees <>
Acked-by: Jeff King <>
Acked-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
5 years agorebase -i: do not leave a CHERRY_PICK_HEAD file behind
Johannes Schindelin [Thu, 18 Jun 2015 16:38:53 +0000 (18:38 +0200)]
rebase -i: do not leave a CHERRY_PICK_HEAD file behind

When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.

The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in, even
before is called.

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
5 years agot3404: demonstrate CHERRY_PICK_HEAD bug
Johannes Schindelin [Thu, 18 Jun 2015 16:38:44 +0000 (18:38 +0200)]
t3404: demonstrate CHERRY_PICK_HEAD bug

When rev-list's --cherry option does not detect that a patch has already
been applied upstream, an interactive rebase would offer to reapply it and
consequently stop at that patch with a failure, mentioning that the diff
is empty.

Traditionally, a `git rebase --continue` simply skips the commit in such a

However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD
behind, making the Git prompt believe that a cherry pick is still going
on. This commit adds a test case demonstrating this bug.

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
5 years agohttp: always use any proxy auth method available
Enrique Tobis [Fri, 26 Jun 2015 18:19:04 +0000 (18:19 +0000)]
http: always use any proxy auth method available

We set CURLOPT_PROXYAUTH to use the most secure authentication
method available only when the user has set configuration variables
to specify a proxy.  However, libcurl also supports specifying a
proxy through environment variables.  In that case libcurl defaults
to only using the Basic proxy authentication method, because we do

Set CURLOPT_PROXYAUTH to always use the most secure authentication
method available, even when there is no git configuration telling us
to use a proxy. This allows the user to use environment variables to
configure a proxy that requires an authentication method different
from Basic.

Signed-off-by: Enrique A. Tobis <>
Signed-off-by: Junio C Hamano <>
5 years agofsck: it is OK for a tag and a commit to lack the body
Junio C Hamano [Sun, 28 Jun 2015 18:18:31 +0000 (11:18 -0700)]
fsck: it is OK for a tag and a commit to lack the body

When fsck validates a commit or a tag, it scans each line in the
header of the object using helper functions such as "start_with()",
etc. that work on a NUL terminated buffer, but before a1e920a0
(index-pack: terminate object buffers with NUL, 2014-12-08), the
validation functions were fed the object data in a piece of memory
that is not necessarily terminated with a NUL.

We added a helper function require_end_of_header() to be called at
the beginning of these validation functions to insist that the
object data contains an empty line before its end.  The theory is
that the validating functions will notice and stop when it hits an
empty line as a normal end of header (or a required header line that
is missing) without scanning past the end of potentially not
NUL-terminated buffer.

But the theory forgot that in the older days, Git itself happily
created objects with only the header lines without a body. This
caused Git 2.2 and later to issue an unnecessary warning in some
existing repositories.

With a1e920a0, we do not need to require an empty line (or the body)
in these objects to safely parse and validate them.  Drop the
offending "must have an empty line" check from this helper function,
while keeping the other check to make sure that there is no NUL in
the header part of the object, and adjust the name of the helper to
what it does accordingly.

Noticed-by: Wolfgang Denk <>
Helped-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'jk/stash-require-clean-index' into maint
Junio C Hamano [Fri, 26 Jun 2015 06:03:26 +0000 (23:03 -0700)]
Merge branch 'jk/stash-require-clean-index' into maint

A hotfix for the topic already in 'master'.

* jk/stash-require-clean-index:
  Revert "stash: require a clean index to apply"

5 years agoMerge branch 'cb/array-size' into maint
Junio C Hamano [Fri, 26 Jun 2015 06:03:25 +0000 (23:03 -0700)]
Merge branch 'cb/array-size' into maint

* cb/array-size:
  Fix definition of ARRAY_SIZE for non-gcc builds

5 years agoGit 2.4.5 v2.4.5
Junio C Hamano [Thu, 25 Jun 2015 18:03:05 +0000 (11:03 -0700)]
Git 2.4.5

Signed-off-by: Junio C Hamano <>
5 years agoMerge branch 'sg/merge-summary-config' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:16 +0000 (11:02 -0700)]
Merge branch 'sg/merge-summary-config' into maint

Doc updates.

* sg/merge-summary-config:
  Documentation: include 'merge.branchdesc' for merge and config as well

5 years agoMerge branch 'jk/make-fix-dependencies' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:15 +0000 (11:02 -0700)]
Merge branch 'jk/make-fix-dependencies' into maint

Build clean-up.

* jk/make-fix-dependencies:
  Makefile: silence perl/PM.stamp recipe
  Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS
  Makefile: drop dependency between git-instaweb and gitweb

5 years agoMerge branch 'sb/pack-protocol-mention-smart-http' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:14 +0000 (11:02 -0700)]
Merge branch 'sb/pack-protocol-mention-smart-http' into maint

Doc updates.

* sb/pack-protocol-mention-smart-http:
  Documentation/technical/pack-protocol: mention http as possible protocol

5 years agoMerge branch 'jk/die-on-bogus-worktree-late' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:13 +0000 (11:02 -0700)]
Merge branch 'jk/die-on-bogus-worktree-late' into maint

The setup code used to die when core.bare and core.worktree are set
inconsistently, even for commands that do not need working tree.

* jk/die-on-bogus-worktree-late:
  setup_git_directory: delay core.bare/core.worktree errors

5 years agoMerge branch 'pt/pull-tags-error-diag' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:12 +0000 (11:02 -0700)]
Merge branch 'pt/pull-tags-error-diag' into maint

There was a dead code that used to handle "git pull --tags" and
show special-cased error message, which was made irrelevant when
the semantics of the option changed back in Git 1.9 days.

* pt/pull-tags-error-diag:
  pull: remove --tags error in no merge candidates case

5 years agoMerge branch 'jk/color-diff-plain-is-context' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:11 +0000 (11:02 -0700)]
Merge branch 'jk/color-diff-plain-is-context' into maint

"color.diff.plain" was a misnomer; give it 'color.diff.context' as
a more logical synonym.

* jk/color-diff-plain-is-context:
  diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT
  diff: accept color.diff.context as a synonym for "plain"

5 years agoMerge branch 'jk/diagnose-config-mmap-failure' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:10 +0000 (11:02 -0700)]
Merge branch 'jk/diagnose-config-mmap-failure' into maint

The configuration reader/writer uses mmap(2) interface to access
the files; when we find a directory, it barfed with "Out of memory?".

* jk/diagnose-config-mmap-failure:
  xmmap(): drop "Out of memory?"
  config.c: rewrite ENODEV into EISDIR when mmap fails
  config.c: avoid xmmap error messages
  config.c: fix mmap leak when writing config
  read-cache.c: drop PROT_WRITE from mmap of index

5 years agoMerge branch 'jk/squelch-missing-link-warning-for-unreachable' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:09 +0000 (11:02 -0700)]
Merge branch 'jk/squelch-missing-link-warning-for-unreachable' into maint

Recent "git prune" traverses young unreachable objects to safekeep
old objects in the reachability chain from them, which sometimes
caused error messages that are unnecessarily alarming.

* jk/squelch-missing-link-warning-for-unreachable:
  suppress errors on missing UNINTERESTING links
  silence broken link warnings with revs->ignore_missing_links
  add quieter versions of parse_{tree,commit}

5 years agoMerge branch 'mm/rebase-i-post-rewrite-exec' into maint
Junio C Hamano [Thu, 25 Jun 2015 18:02:09 +0000 (11:02 -0700)]
Merge branch 'mm/rebase-i-post-rewrite-exec' into maint

"git rebase -i" fired post-rewrite hook when it shouldn't (namely,
when it was told to stop sequencing with 'exec' insn).

* mm/rebase-i-post-rewrite-exec:
  t5407: use <<- to align the expected output
  rebase -i: fix post-rewrite hook with failed exec command
  rebase -i: demonstrate incorrect behavior of post-rewrite

5 years agoFix definition of ARRAY_SIZE for non-gcc builds
Charles Bailey [Wed, 24 Jun 2015 22:12:07 +0000 (23:12 +0100)]
Fix definition of ARRAY_SIZE for non-gcc builds

The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.

Non-gcc builds need this macro to expand to 0 as well. The current outer
test (defined(__GNUC__) && (__GNUC__ >= 3)) is a strictly weaker
condition than the inner test (GIT_GNUC_PREREQ(3, 1)) so we can omit the
outer test and cause the BARF_UNLESS_AN_ARRAY macro to be defined
correctly on non-gcc builds as well as gcc builds with older versions.

Signed-off-by: Charles Bailey <>
Signed-off-by: Junio C Hamano <>
5 years fix color support when tput needs ~/.terminfo
Richard Hansen [Wed, 17 Jun 2015 21:11:21 +0000 (17:11 -0400)] fix color support when tput needs ~/.terminfo

If tput needs ~/.terminfo for the current $TERM, then tput will
succeed before HOME is changed to $TRASH_DIRECTORY (causing color to
be set to 't') but fail afterward.

One possible way to fix this is to treat HOME like TERM: back up the
original value and temporarily restore it before say_color() runs

Instead, pre-compute and save the color control sequences before
changing either TERM or HOME.  Use the saved control sequences in
say_color() rather than call tput each time.  This avoids the need to
back up and restore the TERM and HOME variables, and it avoids the
overhead of a subshell and two invocations of tput per call to

Signed-off-by: Richard Hansen <>
Signed-off-by: Junio C Hamano <>
5 years agodocs: clarify that --encoding can produce invalid sequences
Jeff King [Wed, 17 Jun 2015 18:46:08 +0000 (14:46 -0400)]
docs: clarify that --encoding can produce invalid sequences

In the common case that the commit encoding matches the
output encoding, we do not touch the buffer at all, which
makes things much more efficient. But it might be unclear to
a consumer that we will pass through bogus sequences.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
5 years agogit-checkout.txt: document "git checkout <pathspec>" better
Torsten Bögershausen [Wed, 17 Jun 2015 07:54:51 +0000 (09:54 +0200)]
git-checkout.txt: document "git checkout <pathspec>" better

git checkout <pathspec> can be used to reset changes in the working tree.

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>