gitweb.git
http-walker: fix buffer underflow processing remote... Jeff King Mon, 13 Mar 2017 14:04:45 +0000 (10:04 -0400)

http-walker: fix buffer underflow processing remote alternates

If we parse a remote alternates (or http-alternates), we
expect relative lines like:

../../foo.git/objects

which we convert into "$URL/../foo.git/" (and then use that
as a base for fetching more objects).

But if the remote feeds us nonsense like just:

../

we will try to blindly strip the last 7 characters, assuming
they contain the string "objects". Since we don't _have_ 7
characters at all, this results in feeding a small negative
value to strbuf_add(), which converts it to a size_t,
resulting in a big positive value. This should consistently
fail (since we can't generall allocate the max size_t minus
7 bytes), so there shouldn't be any security implications.

Let's fix this by using strbuf_strip_suffix() to drop the
characters we want. If they're not present, we'll ignore the
alternate (in theory we could use it as-is, but the rest of
the http-walker code unconditionally tacks "objects/" back
on, so it is it not prepared to handle such a case).

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

blame: move blame_entry duplication to add_blame_entry()René Scharfe Fri, 10 Mar 2017 00:12:59 +0000 (01:12 +0100)

blame: move blame_entry duplication to add_blame_entry()

All callers of add_blame_entry() allocate and copy the second argument.
Let the function do it for them, reducing code duplication.

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

t/interop: add test of old clients against modern git... Jeff King Sat, 25 Feb 2017 09:37:30 +0000 (04:37 -0500)

t/interop: add test of old clients against modern git-daemon

This test just checks that old clients can clone and fetch
from a newer git-daemon. The opposite should also be true,
but it's hard to test ancient versions of git-daemon because
they lack basic options like "--listen".

Note that we have to make a slight tweak to the
lib-git-daemon helper from the regular tests, so that it
starts the daemon with our correct git.a version.

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

t: add an interoperability test harnessJeff King Sat, 25 Feb 2017 09:37:07 +0000 (04:37 -0500)

t: add an interoperability test harness

The current test suite is good at letting you test a
particular version of Git. But it's not very good at letting
you test _two_ versions and seeing how they interact (e.g.,
one cloning from the other).

This commit adds a test harness that will build two
arbitrary versions of git and make it easy to call them from
inside your tests. See the README and the example script for
details.

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

real_pathdup(): fix callsites that wanted it to die... Johannes Schindelin Wed, 8 Mar 2017 15:43:40 +0000 (16:43 +0100)

real_pathdup(): fix callsites that wanted it to die on error

In 4ac9006f832 (real_path: have callers use real_pathdup and
strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path())
pattern to use real_pathdup() directly.

The problem with this change is that real_path() calls
strbuf_realpath() with die_on_error = 1 while real_pathdup() calls
it with die_on_error = 0. Meaning that in cases where real_path()
causes Git to die() with an error message, real_pathdup() is silent
and returns NULL instead.

The callers, however, are ill-prepared for that change, as they expect
the return value to be non-NULL (and otherwise the function died
with an appropriate error message).

Fix this by extending real_pathdup()'s signature to accept the
die_on_error flag and simply pass it through to strbuf_realpath(),
and then adjust all callers after a careful audit whether they would
handle NULLs well.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1501: demonstrate NULL pointer access with invalid... Johannes Schindelin Wed, 8 Mar 2017 15:43:34 +0000 (16:43 +0100)

t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE

When GIT_WORK_TREE does not specify a valid path, we should error
out, instead of crashing.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-pack: report signal death of pack-objectsJeff King Tue, 7 Mar 2017 13:39:48 +0000 (08:39 -0500)

send-pack: report signal death of pack-objects

If our pack-objects sub-process dies of a signal, then it
likely didn't have a chance to write anything useful to
stderr. The user may be left scratching their head why the
push failed. Let's detect this situation and write something
to stderr.

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

send-pack: read "unpack" status even on pack-objects... Jeff King Tue, 7 Mar 2017 13:38:51 +0000 (08:38 -0500)

send-pack: read "unpack" status even on pack-objects failure

If the local pack-objects of a push fails, we'll tell the
user about it. But one likely cause is that the remote
index-pack stopped reading for some reason (because it
didn't like our input, or encountered another error). In
that case we'd expect the remote to report more details to
us via the "unpack ..." status line. However, the current
code just hangs up completely, and the user never sees it.

Instead, let's call receive_unpack_status(), which will
complain on stderr with whatever reason the remote told us.
Note that if our pack-objects fails because the connection
was severed or the remote just crashed entirely, then our
packet_read_line() call may fail with "the remote end hung
up unexpectedly". That's OK. It's a more accurate
description than what we get now (which is just "some refs
failed to push").

This should be safe from any deadlocks. At the point we make
this call we'll have closed the writing end of the
connection to the server (either by handing it off to
a pack-objects which exited, explicitly in the stateless_rpc
case, or by doing a half-duplex shutdown for a socket). So
there should be no chance that the other side is waiting
for the rest of our pack-objects input.

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

send-pack: improve unpack-status error messagesJeff King Tue, 7 Mar 2017 13:37:36 +0000 (08:37 -0500)

send-pack: improve unpack-status error messages

When the remote tells us that the "unpack" step failed, we
show an error message. However, unless you are familiar with
the internals of send-pack and receive-pack, it was not
clear that this represented an error on the remote side.
Let's re-word to make that more obvious.

Likewise, when we got an unexpected packet from the other
end, we complained with a vague message but did not actually
show the packet. Let's fix that.

And finally, neither message was marked for translation. The
message from the remote probably won't be translated, but
there's no reason we can't do better for the local half.

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

send-pack: use skip_prefix for parsing unpack statusJeff King Tue, 7 Mar 2017 13:36:19 +0000 (08:36 -0500)

send-pack: use skip_prefix for parsing unpack status

This avoids repeating ourselves, and the use of magic
numbers.

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

send-pack: extract parsing of "unpack" responseJeff King Tue, 7 Mar 2017 13:35:57 +0000 (08:35 -0500)

send-pack: extract parsing of "unpack" response

After sending the pack, we call receive_status() which gets
both the "unpack" line and the ref status. Let's break these
into two functions so we can call the first part
independently.

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

receive-pack: fix deadlock when we cannot create tmpdirJeff King Tue, 7 Mar 2017 13:35:34 +0000 (08:35 -0500)

receive-pack: fix deadlock when we cannot create tmpdir

The err_fd descriptor passed to the unpack() function is
intended to be handed off to the child index-pack, and our
async muxer will read until it gets EOF. However, if we
encounter an error before handing off the descriptor, we
must manually close(err_fd). Otherwise we will be waiting
for our muxer to finish, while the muxer is waiting for EOF
on err_fd.

We fixed an identical deadlock already in 49ecfa13f
(receive-pack: close sideband fd on early pack errors,
2013-04-19). But since then, the function grew a new
early-return in 722ff7f87 (receive-pack: quarantine objects
until pre-receive accepts, 2016-10-03), when we fail to
create a temporary directory. This return needs the same
treatment.

Reported-by: Horst Schirmeier <horst@schirmeier.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ewah: fix eword_t/uint64_t confusionJeff King Sun, 5 Mar 2017 11:46:38 +0000 (06:46 -0500)

ewah: fix eword_t/uint64_t confusion

The ewah subsystem typedefs eword_t to be uint64_t, but some
code uses a bare uint64_t. This isn't a bug now, but it's a
potential maintenance problem if the definition of eword_t
ever changes. Let's use the correct type.

Note that we can't use COPY_ARRAY() here because the source
and destination point to objects of different sizes. For
that reason we'll also skip the usual "sizeof(*dst)" and use
the real type, which should make it more clear that there's
something tricky going on.

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

line-log: use COPY_ARRAY to fix mis-sized memcpyVegard Nossum Sun, 5 Mar 2017 11:44:46 +0000 (06:44 -0500)

line-log: use COPY_ARRAY to fix mis-sized memcpy

This memcpy meant to get the sizeof a "struct range", not a
"range_set", as the former is what our array holds. Rather
than swap out the types, let's convert this site to
COPY_ARRAY, which avoids the problem entirely (and confirms
that the src and dst types match).

Note for curiosity's sake that this bug doesn't trigger on
I32LP64 systems, but does on ILP32 systems. The mistaken
"struct range_set" has two ints and a pointer. That's 16
bytes on LP64, or 12 on ILP32. The correct "struct range"
type has two longs, which is also 16 on LP64, but only 8 on
ILP32.

Likewise an IL32P64 system would experience the bug.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Travis: also test on 32-bit LinuxJohannes Schindelin Sun, 5 Mar 2017 18:25:19 +0000 (19:25 +0100)

Travis: also test on 32-bit Linux

When Git v2.9.1 was released, it had a bug that showed only on Windows
and on 32-bit systems: our assumption that `unsigned long` can hold
64-bit values turned out to be wrong.

This could have been caught earlier if we had a Continuous Testing
set up that includes a build and test run on 32-bit Linux.

Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: release strbuf on disabled alternatesEric Wong Sat, 4 Mar 2017 01:50:16 +0000 (01:50 +0000)

http: release strbuf on disabled alternates

This likely has no real-world impact on memory usage,
but it is cleaner for future readers.

Fixes: abcbdc03895f ("http: respect protocol.*.allow=user for http-alternates")
Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: inform about alternates-as-redirects behaviorEric Wong Sat, 4 Mar 2017 08:36:45 +0000 (08:36 +0000)

http: inform about alternates-as-redirects behavior

It is disconcerting for users to not notice the behavior
change in handling alternates from commit cb4d2d35c4622ec2
("http: treat http-alternates like redirects")

Give the user a hint about the config option so they can
see the URL and decide whether or not they want to enable
http.followRedirects in their config.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

p7000: add test for filter-branch with --prune-emptyDevin J. Pohly Thu, 23 Feb 2017 08:27:36 +0000 (02:27 -0600)

p7000: add test for filter-branch with --prune-empty

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: fix --prune-empty on parentless commitsDevin J. Pohly Thu, 23 Feb 2017 08:27:35 +0000 (02:27 -0600)

filter-branch: fix --prune-empty on parentless commits

Previously, the git_commit_non_empty_tree function would always pass any
commit with no parents to git-commit-tree, regardless of whether the
tree was nonempty. The new commit would then be recorded in the
filter-branch revision map, and subsequent commits which leave the tree
untouched would be correctly filtered.

With this change, parentless commits with an empty tree are correctly
pruned, and an empty file is recorded in the revision map, signifying
that it was rewritten to "no commits." This works naturally with the
parent mapping for subsequent commits.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7003: ensure --prune-empty removes entire branch when... Devin J. Pohly Thu, 23 Feb 2017 08:27:34 +0000 (02:27 -0600)

t7003: ensure --prune-empty removes entire branch when applicable

Sanity check before changing the logic in git_commit_non_empty_tree.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7003: ensure --prune-empty can prune root commitDevin J. Pohly Thu, 23 Feb 2017 08:27:33 +0000 (02:27 -0600)

t7003: ensure --prune-empty can prune root commit

New test to expose a bug in filter-branch whereby the root commit is
never pruned, even though its tree is empty and --prune-empty is given.

The setup isn't exactly pretty, but I couldn't think of a simpler way to
create a parallel commit graph sans the first commit.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

line-log.c: prevent crash during union of too many... Allan Xavier Thu, 2 Mar 2017 17:29:02 +0000 (17:29 +0000)

line-log.c: prevent crash during union of too many ranges

The existing implementation of range_set_union does not correctly
reallocate memory, leading to a heap overflow when it attempts to union
more than 24 separate line ranges.

For struct range_set *out to grow correctly it must have out->nr set to
the current size of the buffer when it is passed to range_set_grow.
However, the existing implementation of range_set_union only updates
out->nr at the end of the function, meaning that it is always zero
before this. This results in range_set_grow never growing the buffer, as
well as some of the union logic itself being incorrect as !out->nr is
always true.

The reason why 24 is the limit is that the first allocation of size 1
ends up allocating a buffer of size 24 (due to the call to alloc_nr in
ALLOC_GROW). This goes some way to explain why this hasn't been
caught before.

Fix the problem by correctly updating out->nr after reallocating the
range_set. As this results in out->nr containing the same value as the
variable o, replace o with out->nr as well.

Finally, add a new test to help prevent the problem reoccurring in the
future. Thanks to Vegard Nossum for writing the test.

Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib: git-remote-{bzr,hg} placeholders don't need... Sebastian Schuberth Fri, 3 Mar 2017 10:57:46 +0000 (10:57 +0000)

contrib: git-remote-{bzr,hg} placeholders don't need Python

It does not make sense for these placeholder scripts to depend on Python
just because the real scripts do. At the example of Git for Windows, we
would not even be able to see those warnings as it does not ship with
Python. So just use plain shell scripts instead.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/perf: add fallback for pre-bin-wrappers versions... Jeff King Fri, 3 Mar 2017 07:36:33 +0000 (02:36 -0500)

t/perf: add fallback for pre-bin-wrappers versions of git

It's tempting to say:

./run v1.0.0 HEAD

to see how we've sped up Git over the years. Unfortunately,
this doesn't quite work because versions of Git prior to
v1.7.0 lack bin-wrappers, so our "run" script doesn't
correctly put them in the PATH.

Worse, it means we silently find whatever other "git" is in
the PATH, and produce test results that have no bearing on
what we asked for.

Let's fallback to the main git directory when bin-wrappers
isn't present. Many modern perf scripts won't run with such
an antique version of Git, of course, but at least those
failures are detected and reported (and you're free to write
a limited perf script that works across many versions).

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

t/perf: use $MODERN_GIT for all repo-copying stepsJeff King Fri, 3 Mar 2017 07:14:03 +0000 (02:14 -0500)

t/perf: use $MODERN_GIT for all repo-copying steps

Since 1a0962dee (t/perf: fix regression in testing older
versions of git, 2016-06-22), we point "$MODERN_GIT" to a
copy of git that matches the t/perf script itself, and which
can be used for tasks outside of the actual timings. This is
needed because the setup done by perf scripts keeps moving
forward in time, and may use features that the older
versions of git we are testing do not have.

That commit used $MODERN_GIT to fix a case where we relied
on the relatively recent --git-path option. But if you go
back further still, there are more problems.

Since 7501b5921 (perf: make the tests work in worktrees,
2016-05-13), we use "git -C", but versions of git older than
44e1e4d67 (git: run in a directory given with -C option,
2013-09-09) don't know about "-C". So testing an old version
of git with a new version of t/perf will fail the setup
step.

We can fix this by using $MODERN_GIT during the setup;
there's no need to use the antique version, since it doesn't
affect the timings. Likewise, we'll adjust the "init"
invocation; antique versions of git called this "init-db".

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

t/perf: export variable used in other blocksJonathan Tan Thu, 2 Mar 2017 19:50:41 +0000 (11:50 -0800)

t/perf: export variable used in other blocks

In p0001, a variable was created in a test_expect_success block to be
used in later test_perf blocks, but was not exported. This caused the
variable to not appear in those blocks (this can be verified by writing
'test -n "$commit"' in those blocks), resulting in a slightly different
invocation than what was intended. Export that variable.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: add specific error for fetching an unadvert... Matt McCutchen Wed, 22 Feb 2017 16:05:57 +0000 (11:05 -0500)

fetch-pack: add specific error for fetching an unadvertised object

Enhance filter_refs (which decides whether a request for an unadvertised
object should be sent to the server) to record a new match status on the
"struct ref" when a request is not allowed, and have
report_unmatched_refs check for this status and print a special error
message, "Server does not allow request for unadvertised object".

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch_refs_via_pack: call report_unmatched_refsMatt McCutchen Wed, 22 Feb 2017 16:02:15 +0000 (11:02 -0500)

fetch_refs_via_pack: call report_unmatched_refs

"git fetch" currently doesn't bother to check that it got all refs it
sought, because the common case of requesting a nonexistent ref triggers
a die() in get_fetch_map. However, there's at least one case that
slipped through: "git fetch REMOTE SHA1" if the server doesn't allow
requests for unadvertised objects. Make fetch_refs_via_pack (which is
on the "git fetch" code path) call report_unmatched_refs so that we at
least get an error message in that case.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: move code to report unmatched refs to a... Matt McCutchen Wed, 22 Feb 2017 16:01:22 +0000 (11:01 -0500)

fetch-pack: move code to report unmatched refs to a function

Prepare to reuse this code in transport.c for "git fetch".

While we're here, internationalize the existing error message.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: restrict @-expansions when finding branchJeff King Thu, 2 Mar 2017 08:23:18 +0000 (03:23 -0500)

checkout: restrict @-expansions when finding branch

When we parse "git checkout $NAME", we try to interpret
$NAME as a local branch-name. If it is, then we point HEAD
to that branch. Otherwise, we detach the HEAD at whatever
commit $NAME points to.

We do the interpretation by calling strbuf_branchname(), and
then blindly sticking "refs/heads/" on the front. This leads
to nonsense results when expansions like "@{upstream}" or
"@" point to something besides a local branch. We end up
with a local branch name like "refs/heads/origin/master" or
"refs/heads/HEAD".

Normally this has no user-visible effect because those
branches don't exist, and so we fallback to feeding the
result to get_sha1(), which resolves them correctly.

But as the new test in t3204 shows, there are corner cases
where the effect is observable, and we check out the wrong
local branch rather than detaching to the correct one.

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

strbuf_check_ref_format(): expand only local branchesJeff King Thu, 2 Mar 2017 08:23:14 +0000 (03:23 -0500)

strbuf_check_ref_format(): expand only local branches

This function asks strbuf_branchname() to expand any @-marks
in the branchname, and then we blindly stick refs/heads/ in
front of the result. This is obviously nonsense if the
expansion is "HEAD" or a ref in refs/remotes/.

The most obvious end-user effect is that creating or
renaming a branch with an expansion may have confusing
results (e.g., creating refs/heads/origin/master from
"@{upstream}" when the operation should be disallowed).

We can fix this by telling strbuf_branchname() that we are
only interested in local expansions. Any unexpanded bits are
then fed to check_ref_format(), which either disallows them
(in the case of "@{upstream}") or lets them through
("refs/heads/@" is technically valid, if a bit silly).

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

branch: restrict @-expansions when deletingJeff King Thu, 2 Mar 2017 08:23:10 +0000 (03:23 -0500)

branch: restrict @-expansions when deleting

We use strbuf_branchname() to expand the branch name from
the command line, so you can delete the branch given by
@{-1}, for example. However, we allow other nonsense like
"@", and we do not respect our "-r" flag (so we may end up
deleting an oddly-named local ref instead of a remote one).

We can fix this by passing the appropriate "allowed" flag to
strbuf_branchname().

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

t3204: test git-branch @-expansion corner casesJeff King Thu, 2 Mar 2017 08:23:06 +0000 (03:23 -0500)

t3204: test git-branch @-expansion corner cases

git-branch feeds the branch names from the command line to
strbuf_branchname(), but we do not yet tell that function
which kinds of expansions should be allowed. Let's create a
set of tests that cover both the allowed and disallowed
cases.

That shows off some breakages where we currently create or
delete the wrong ref (and will make sure that we do not
break any cases that _should_ be working when we do add more
restrictions).

Note that we check branch creation and deletion, but do not
bother with renames. Those follow the same code path as
creation.

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

interpret_branch_name: allow callers to restrict expansionsJeff King Thu, 2 Mar 2017 08:23:01 +0000 (03:23 -0500)

interpret_branch_name: allow callers to restrict expansions

The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").

This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).

Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").

However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).

The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.

We can break the callers down into two groups:

1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().

2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.

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

strbuf_branchname: add docstringJeff King Thu, 2 Mar 2017 08:21:30 +0000 (03:21 -0500)

strbuf_branchname: add docstring

This function and its companion, strbuf_check_branch_ref(),
did not have their purpose or semantics explained. Let's do
so.

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

strbuf_branchname: drop return valueJeff King Thu, 2 Mar 2017 08:21:27 +0000 (03:21 -0500)

strbuf_branchname: drop return value

The return value from strbuf_branchname() is confusing and
useless: it's 0 if the whole name was consumed by an @-mark,
but otherwise is the length of the original name we fed.

No callers actually look at the return value, so let's just
get rid of it.

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

interpret_branch_name: move docstring to header fileJeff King Thu, 2 Mar 2017 08:21:23 +0000 (03:21 -0500)

interpret_branch_name: move docstring to header file

We generally put docstrings with function declarations,
because it's the callers who need to know how the function
works. Let's do so for interpret_branch_name().

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

interpret_branch_name(): handle auto-namelen for @{-1}Jeff King Mon, 27 Feb 2017 09:25:40 +0000 (04:25 -0500)

interpret_branch_name(): handle auto-namelen for @{-1}

The interpret_branch_name() function takes a ptr/len pair
for the name, but you can pass "0" for "namelen", which will
cause it to check the length with strlen().

However, before we do that auto-namelen magic, we call
interpret_nth_prior_checkout(), which gets fed the bogus
"0". This was broken by 8cd4249c4 (interpret_branch_name:
always respect "namelen" parameter, 2014-01-15). Though to
be fair to that commit, it was broken in the _opposite_
direction before, where we would always treat "name" as a
string even if a length was passed.

You can see the bug with "git log -g @{-1}". That code path
always passes "0", and without this patch it cannot figure
out which branch's reflog to show.

We can fix it by a small reordering of the code.

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

diff: do not short-cut CHECK_SIZE_ONLY check in diff_po... Junio C Hamano Wed, 1 Mar 2017 17:04:44 +0000 (18:04 +0100)

diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()

Callers of diff_populate_filespec() can choose to ask only for the
size of the blob without grabbing the blob data, and the function,
after running lstat() when the filespec points at a working tree
file, returns by copying the value in size field of the stat
structure into the size field of the filespec when this is the case.

However, this short-cut cannot be taken if the contents from the
path needs to go through convert_to_git(), whose resulting real blob
data may be different from what is in the working tree file.

As "git diff --quiet" compares the .size fields of filespec
structures to skip content comparison, this bug manifests as a
false "there are differences" for a file that needs eol conversion,
for example.

Reported-by: Mike Crowe <mac@mcrowe.com>
Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add--interactive: fix missing file prompt for patch... Jeff King Thu, 2 Mar 2017 09:48:22 +0000 (04:48 -0500)

add--interactive: fix missing file prompt for patch mode with "-i"

When invoked as "git add -i", each menu interactive menu
option prompts the user to select a list of files. This
includes the "patch" option, which gets the list before
starting the hunk-selection loop.

As "git add -p", it behaves differently, and jumps straight
to the hunk selection loop.

Since 0539d5e6d (i18n: add--interactive: mark patch prompt
for translation, 2016-12-14), the "add -i" case mistakenly
jumps to straight to the hunk-selection loop. Prior to that
commit the distinction between the two cases was managed by
the $patch_mode variable. That commit used $patch_mode for
something else, and moved the old meaning to the "$cmd"
variable. But it forgot to update the $patch_mode check
inside patch_update_cmd() which controls the file-list
behavior.

The simplest fix would be to change that line to check $cmd.
But while we're here, let's use a less obscure name for this
flag: $patch_mode_only, a boolean which tells whether we are
in full-interactive mode or only in patch-mode.

Reported-by: Henrik Grubbström <grubba@grubba.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

README: create HTTP/HTTPS links from URLs in MarkdownEric Wong Wed, 1 Mar 2017 22:22:04 +0000 (22:22 +0000)

README: create HTTP/HTTPS links from URLs in Markdown

Markdown supports automatic links by surrounding URLs with
angle brackets, as documented in
<https://daringfireball.net/projects/markdown/syntax#autolink>

While we're at it, update URLs to avoid redirecting clients for
git-scm.com (by using HTTPS) and public-inbox.org (by adding a
trailing slash).

Signed-off-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb tests: skip tests when we don't have Time::HiResÆvar Arnfjörð Bjarmason Wed, 1 Mar 2017 21:15:40 +0000 (21:15 +0000)

gitweb tests: skip tests when we don't have Time::HiRes

Change the gitweb tests to skip when we can't load the Time::HiRes
module.

Gitweb needs this module to work. It has been in perl core since v5.8,
which is the oldest version we support. However CentOS (and perhaps
some other distributions) carve it into its own non-core-perl package
that's not installed along with /usr/bin/perl by default. Without this
we'll hard fail the gitweb tests when trying to load the module.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb tests: change confusing "skip_all" phrasingÆvar Arnfjörð Bjarmason Wed, 1 Mar 2017 21:15:39 +0000 (21:15 +0000)

gitweb tests: change confusing "skip_all" phrasing

Change the phrasing so that instead of saying that the CGI module is
unusable, we say that it's not available.

This came up on the git mailing list in
<4b34e3a0-3da7-d821-2a7f-9a420ac1d3f6@gmail.com> from Jakub Narębski.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wrapper.c: remove unused gitmkstemps() functionRamsay Jones Tue, 28 Feb 2017 01:26:06 +0000 (01:26 +0000)

wrapper.c: remove unused gitmkstemps() function

The last call to the mkstemps() function was removed in commit 659488326
("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order
to support platforms without mkstemps(), this functionality was provided,
along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps()
function. Remove the dead code, along with the defunct build machinery.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wrapper.c: remove unused git_mkstemp() functionRamsay Jones Tue, 28 Feb 2017 01:24:10 +0000 (01:24 +0000)

wrapper.c: remove unused git_mkstemp() function

The last caller of git_mkstemp() was removed in commit 6fec0a89
("verify_signed_buffer: use tempfile object", 16-06-2016). Since
the introduction of the 'tempfile' APIs, along with git_mkstemp_mode,
it is unlikely that new callers will materialize. Remove the dead
code.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: attempt updating base URL only if no errorJonathan Tan Tue, 28 Feb 2017 02:53:11 +0000 (18:53 -0800)

http: attempt updating base URL only if no error

http.c supports HTTP redirects of the form

http://foo/info/refs?service=git-upload-pack
-> http://anything
-> http://bar/info/refs?service=git-upload-pack

(that is to say, as long as the Git part of the path and the query
string is preserved in the final redirect destination, the intermediate
steps can have any URL). However, if one of the intermediate steps
results in an HTTP exception, a confusing "unable to update url base
from redirection" message is printed instead of a Curl error message
with the HTTP exception code.

This was introduced by 2 commits. Commit c93c92f ("http: update base
URLs when we see redirects", 2013-09-28) introduced a best-effort
optimization that required checking if only the "base" part of the URL
differed between the initial request and the final redirect destination,
but it performed the check before any HTTP status checking was done. If
something went wrong, the normal code path was still followed, so this
did not cause any confusing error messages until commit 6628eb4 ("http:
always update the base URL for redirects", 2016-12-06), which taught
http to die if the non-"base" part of the URL differed.

Therefore, teach http to check the HTTP status before attempting to
check if only the "base" part of the URL differed. This commit teaches
http_request_reauth to return early without updating options->base_url
upon an error; the only invoker of this function that passes a non-NULL
"options" is remote-curl.c (through "http_get_strbuf"), which only uses
options->base_url for an informational message in the situations that
this commit cares about (that is, when the return value is not HTTP_OK).

The included test checks that the redirect scheme at the beginning of
this commit message works, and that returning a 502 in the middle of the
redirect scheme produces the correct result. Note that this is different
from the test in commit 6628eb4 ("http: always update the base URL for
redirects", 2016-12-06) in that this commit tests that a Git-shaped URL
(http://.../info/refs?service=git-upload-pack) works, whereas commit
6628eb4 tests that a non-Git-shaped URL
(http://.../info/refs/foo?service=git-upload-pack) does not work (even
though Git is processing that URL) and is an error that is fatal, not
silently swallowed.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs/diffcore: unquote "Complete Rewrites" in headersPatrick Steinhardt Tue, 28 Feb 2017 08:59:05 +0000 (09:59 +0100)

docs/diffcore: unquote "Complete Rewrites" in headers

The gitdiffcore documentation quotes the term "Complete Rewrites" in
headers for no real gain. This would make sense if the term could be
easily confused if not properly grouped together. But actually, the term
is quite obvious and thus does not really need any quoting, especially
regarding that it is not used anywhere else.

But more importanly, this brings up a bug when rendering man pages: when
trying to render quotes inside of a section header, we end up with
quotes which have been misaligned to the end of line. E.g.

diffcore-break: For Splitting Up Complete Rewrites
--------------------------------------------------

renders as

DIFFCORE-BREAK: FOR SPLITTING UP COMPLETE REWRITES""

, which is obviously wrong. While this is fixable for the man pages by
using double-quotes (e.g. ""COMPLETE REWRITES""), this again breaks it
for our generated HTML pages.

So fix the issue by simply dropping quotes inside of section headers,
which is currently only done for the term "Complete Rewrites".

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs/diffcore: fix grammar in diffcore-rename headerPatrick Steinhardt Tue, 28 Feb 2017 08:59:04 +0000 (09:59 +0100)

docs/diffcore: fix grammar in diffcore-rename header

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cvs tests: skip tests that call "cvs commit" when runni... Ævar Arnfjörð Bjarmason Mon, 27 Feb 2017 11:26:28 +0000 (11:26 +0000)

cvs tests: skip tests that call "cvs commit" when running as root

Change the tests that fail to when we run the test suite as root, due
to calling "cvs commit".

The GNU cvs package has an optional compile-time CVS_BADROOT
flag. When compiled with this flag "cvs commit" will refuse to commit
anything as root. On my Debian box this isn't compiled in[1] in, but
on CentOS it is.

I've run all the t/t*cvs*.sh tests, and these are the only two that
fail. For some reason e.g. t9402-git-cvsserver-refs.sh still works as
root despite doing "cvs commit", I haven't dug into why.

This commit is technically being overzealous, we could do better by
making a mock cvs commit as root and run the tests if that works, but
I don't see any compelling reason to bend over backwards to run these
tests in all cases, just skipping them as root seems good enough.

1. Per: strings /usr/bin/cvs|grep 'is not allowed to commit'
Using cvs 1.11.23 on CentOS, 1.12.13-MirDebian-18 on Debian.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6300: avoid creating refs/heads/HEADJeff King Mon, 27 Feb 2017 09:29:31 +0000 (04:29 -0500)

t6300: avoid creating refs/heads/HEAD

In one test, we use "git checkout --orphan HEAD" to create
an unborn branch. Confusingly, the resulting branch is named
"refs/heads/HEAD". The original probably meant something
like:

git checkout --orphan orphaned-branch HEAD

Let's just use "orphaned-branch" here to make this less
confusing. Putting HEAD in the second argument is already
implied.

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

commit: don't check for space twice when looking for... René Scharfe Sat, 25 Feb 2017 19:27:40 +0000 (20:27 +0100)

commit: don't check for space twice when looking for header

Both standard_header_field() and excluded_header_field() check if
there's a space after the buffer that's handed to them. We already
check in the caller if that space is present. Don't bother calling
the functions if it's missing, as they are guaranteed to return 0 in
that case, and remove the now redundant checks from them.

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

commit: be more precise when searching for headersRené Scharfe Sat, 25 Feb 2017 19:21:52 +0000 (20:21 +0100)

commit: be more precise when searching for headers

Search for a space character only within the current line in
read_commit_extra_header_lines() instead of searching in the whole
buffer (and possibly beyond, if it's not NUL-terminated) and then
discarding any results after the end of the current line.

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

strbuf: add strbuf_add_real_path()René Scharfe Sat, 25 Feb 2017 16:00:33 +0000 (17:00 +0100)

strbuf: add strbuf_add_real_path()

Add a function for appending the canonized absolute pathname of a given
path to a strbuf. It keeps the existing contents intact, as expected of
a function of the strbuf_add() family, while avoiding copying the result
if the given strbuf is empty. It's more consistent with the rest of the
strbuf API than strbuf_realpath(), which it's wrapping.

Also add a semantic patch demonstrating its intended usage and apply it
to the current tree. Using strbuf_add_real_path() instead of calling
strbuf_addstr() and real_path() avoids an extra copy to a static buffer.

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

cocci: use ALLOC_ARRAYRené Scharfe Sat, 25 Feb 2017 10:30:03 +0000 (11:30 +0100)

cocci: use ALLOC_ARRAY

Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply
the transformation on the current source tree. The macro checks for
multiplication overflow and infers the element size automatically; the
result is shorter and safer code.

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

sha1_file: release fallback base's memory in unpack_entry()René Scharfe Sat, 25 Feb 2017 10:02:28 +0000 (11:02 +0100)

sha1_file: release fallback base's memory in unpack_entry()

If a pack entry that's used as a delta base is corrupt, unpack_entry()
marks it as unusable and then searches the object again in the hope that
it can be found in another pack or in a loose file. The memory for this
external base object is never released. Free it after use.

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

http: add an "auto" mode for http.emptyauthJeff King Sat, 25 Feb 2017 19:18:31 +0000 (14:18 -0500)

http: add an "auto" mode for http.emptyauth

This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.

However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.

Instead, let's introduce an automatic mode, that works like
this:

1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.

2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").

That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.

This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).

The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.

Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: only allow one address per body tagJohan Hovold Mon, 20 Feb 2017 11:44:06 +0000 (12:44 +0100)

send-email: only allow one address per body tag

Adding comments after a tag in the body is a common practise (e.g. in
the Linux kernel) and git-send-email has been supporting this for years
by removing any trailing cruft after the address.

After some recent changes, any trailing comment is now instead appended
to the recipient name (with some random white space inserted) resulting
in undesirable noise in the headers, for example:

CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org>
Revert to the earlier behaviour of discarding anything after the (first)
address in a tag while parsing the body.

Note that multiple addresses after are still allowed after a command
line switch (and in a CC header field).

Also note that --suppress-cc=self was never honoured when using multiple
addresses in a tag.

Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

parse_hide_refs_config: tell parse_config_key we don... Jeff King Fri, 24 Feb 2017 21:08:16 +0000 (16:08 -0500)

parse_hide_refs_config: tell parse_config_key we don't want a subsection

This lets us avoid declaring some otherwise useless
variables.

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

parse_config_key: allow matching single-level configJeff King Fri, 24 Feb 2017 21:08:02 +0000 (16:08 -0500)

parse_config_key: allow matching single-level config

The parse_config_key() function was introduced to make it
easier to match "section.subsection.key" variables. It also
handles the simpler "section.key", and the caller is
responsible for distinguishing the two from its
out-parameters.

Most callers who _only_ want "section.key" would just use a
strcmp(var, "section.key"), since there is no parsing
required. However, they may still use parse_config_key() if
their "section" variable isn't a constant (an example of
this is in parse_hide_refs_config).

Using the parse_config_key is a bit clunky, though:

const char *subsection;
int subsection_len;
const char *key;

if (!parse_config_key(var, section, &subsection, &subsection_len, &key) &&
!subsection) {
/* matched! */
}

Instead, let's treat a NULL subsection as an indication that
the caller does not expect one. That lets us write:

const char *key;

if (!parse_config_key(var, section, NULL, NULL, &key)) {
/* matched! */
}

Existing callers should be unaffected, as passing a NULL
subsection would currently segfault.

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

parse_config_key: use skip_prefix instead of starts_withJeff King Fri, 24 Feb 2017 21:07:19 +0000 (16:07 -0500)

parse_config_key: use skip_prefix instead of starts_with

This saves us having to repeatedly add in "section_len" (and
also avoids walking over the first part of the string
multiple times for a strlen() and strrchr()).

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

refs: parse_hide_refs_config to use parse_config_keyStefan Beller Fri, 24 Feb 2017 20:43:35 +0000 (12:43 -0800)

refs: parse_hide_refs_config to use parse_config_key

parse_config_key was introduced in 1b86bbb0ade (config: add helper
function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
in this patch was introduced at daebaa7813 (upload/receive-pack: allow
hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
so presumably the code replaced in this patch was only introduced due
to not wanting to wait on the proper helper function being available.

Make the condition easier to read by using parse_config_key.

Signed-off-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.12 v2.12.0Junio C Hamano Fri, 24 Feb 2017 18:49:58 +0000 (10:49 -0800)

Git 2.12

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

Merge branch 'ps/doc-gc-aggressive-depth-update'Junio C Hamano Fri, 24 Feb 2017 18:48:10 +0000 (10:48 -0800)

Merge branch 'ps/doc-gc-aggressive-depth-update'

Doc update.

* ps/doc-gc-aggressive-depth-update:
docs/git-gc: fix default value for `--aggressiveDepth`

Merge branch 'bc/worktree-doc-fix-detached'Junio C Hamano Fri, 24 Feb 2017 18:48:10 +0000 (10:48 -0800)

Merge branch 'bc/worktree-doc-fix-detached'

Doc update.

* bc/worktree-doc-fix-detached:
Documentation: correctly spell git worktree --detach

Merge branch 'dr/doc-check-ref-format-normalize'Junio C Hamano Fri, 24 Feb 2017 18:48:09 +0000 (10:48 -0800)

Merge branch 'dr/doc-check-ref-format-normalize'

Doc update.

* dr/doc-check-ref-format-normalize:
git-check-ref-format: clarify documentation for --normalize

Merge branch 'gp/document-dotfiles-in-templates-are... Junio C Hamano Fri, 24 Feb 2017 18:48:09 +0000 (10:48 -0800)

Merge branch 'gp/document-dotfiles-in-templates-are-not-copied'

Doc update.

* gp/document-dotfiles-in-templates-are-not-copied:
init: document dotfiles exclusion on template copy

Merge branch 'rt/align-add-i-help-text'Junio C Hamano Fri, 24 Feb 2017 18:48:08 +0000 (10:48 -0800)

Merge branch 'rt/align-add-i-help-text'

Doc update.

* rt/align-add-i-help-text:
git add -i: replace \t with blanks in the help message

Merge branch 'bc/blame-doc-fix'Junio C Hamano Fri, 24 Feb 2017 18:48:07 +0000 (10:48 -0800)

Merge branch 'bc/blame-doc-fix'

Doc update.

* bc/blame-doc-fix:
Documentation: use brackets for optional arguments

docs/git-gc: fix default value for `--aggressiveDepth`Patrick Steinhardt Fri, 24 Feb 2017 08:46:45 +0000 (09:46 +0100)

docs/git-gc: fix default value for `--aggressiveDepth`

In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11),
the default aggressive depth of git-gc has been changed to 50. While
git-config(1) has been updated to represent the new default value,
git-gc(1) still mentions the old value. This patch fixes it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge tag 'l10n-2.12.0-rnd2' of git://github.com/git... Junio C Hamano Fri, 24 Feb 2017 17:55:41 +0000 (09:55 -0800)

Merge tag 'l10n-2.12.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.12.0-rnd2

* tag 'l10n-2.12.0-rnd2' of git://github.com/git-l10n/git-po: (22 commits)
l10n: zh_CN: for git v2.12.0 l10n round 2
l10n: Update Catalan translation
l10n: pt_PT: update Portuguese tranlation
l10n: sv.po: Update Swedish translation (3139t0f0u)
l10n: de.po: translate 241 messages
l10n: ko.po: Update Korean translation
l10n: vi.po (3139t): Updated 2 new messages for rc1
l10n: fr.po: v2.12.0 round 2 3139t
l10n: git.pot: v2.12.0 round 2 (2 new)
l10n: vi.po: Updated Vietnamese translation (3137t)
l10n: update Catalan translation
l10n: sv.po: Update Swedish translation (3137t0f0u)
l10n: fr.po: v2.11-rc0 first round
l10n: ko.po: Update Korean translation
l10n: fr.po: Fix a typo in the French translation
l10n: fr.po: Remove gender specific adjectives
l10n: fr.po: Fix typos
l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed)
l10n: bg: Updated Bulgarian translation (2913t+0f+0u)
l10n: fixes to Catalan translation
...

l10n: zh_CN: for git v2.12.0 l10n round 2Jiang Xin Fri, 27 Jan 2017 14:50:57 +0000 (22:50 +0800)

l10n: zh_CN: for git v2.12.0 l10n round 2

Translate 241 messages (3139t0f0u) for git v2.12.0-rc1.

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

l10n: Update Catalan translationJordi Mas Tue, 21 Feb 2017 17:32:29 +0000 (18:32 +0100)

l10n: Update Catalan translation

Signed-off-by: Jordi Mas <jmas@softcatala.org>

config: use git_config_parse_key() in git_config_parse_... Junio C Hamano Thu, 23 Feb 2017 23:04:40 +0000 (15:04 -0800)

config: use git_config_parse_key() in git_config_parse_parameter()

The parsing of one-shot assignments of configuration variables that
come from the command line historically was quite loose and allowed
anything to pass. It also downcased everything in the variable name,
even a three-level <section>.<subsection>.<variable> name in which
the <subsection> part must be treated in a case sensitive manner.

Existing git_config_parse_key() helper is used to parse the variable
name that comes from the command line, i.e. "git config VAR VAL",
and handles these details correctly. Replace the strbuf_tolower()
call in git_config_parse_parameter() with a call to it to correct
both issues. git_config_parse_key() does a bit more things that are
not necessary for the purpose of this codepath (e.g. it allocates a
separate buffer to return the canonicalized variable name because it
takes a "const char *" input), but we are not in a performance-critical
codepath here.

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

config: move a few helper functions upJunio C Hamano Thu, 23 Feb 2017 22:44:07 +0000 (14:44 -0800)

config: move a few helper functions up

git_config_parse_key() implements the validation and downcasing of
<section> and <variable> in "<section>[.<subsection>].<variable>"
configuration variable name. Move it (and helpers it uses) a bit up
so that it can be used by git_config_parse_parameter(), which is
used to check configuration settings that are given on the command
line (i.e. "git -c VAR=VAL cmd"), in a later patch.

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

ident: do not ignore empty config name/emailJeff King Thu, 23 Feb 2017 08:17:08 +0000 (03:17 -0500)

ident: do not ignore empty config name/email

When we read user.name and user.email from a config file,
they go into strbufs. When a caller asks ident_default_name()
for the value, we fallback to auto-detecting if the strbuf
is empty.

That means that explicitly setting an empty string in the
config is identical to not setting it at all. This is
potentially confusing, as we usually accept a configured
value as the final value.

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

ident: reject all-crud ident nameJeff King Thu, 23 Feb 2017 08:15:55 +0000 (03:15 -0500)

ident: reject all-crud ident name

An ident name consisting of only "crud" characters (like
whitespace or punctuation) is effectively the same as an
empty one, because our strbuf_addstr_without_crud() will
remove those characters.

We reject an empty name when formatting a strict ident, but
don't notice an all-crud one because our check happens
before the crud-removal step.

We could skip past the crud before checking for an empty
name, but let's make it a separate code path, for two
reasons. One is that we can give a more specific error
message. And two is that unlike a blank name, we probably
don't want to kick in the fallback-to-username behavior.

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

ident: handle NULL email when complaining of empty... Jeff King Thu, 23 Feb 2017 08:13:53 +0000 (03:13 -0500)

ident: handle NULL email when complaining of empty name

If we see an empty name, we complain about and mention the
matching email in the error message (to give it some
context). However, the "email" pointer may be NULL here if
we were planning to fill it in later from ident_default_email().

This was broken by 59f929596 (fmt_ident: refactor strictness
checks, 2016-02-04). Prior to that commit, we would look up
the default name and email before doing any other actions.
So one solution would be to go back to that.

However, we can't just do so blindly. The logic for handling
the "!email" condition has grown since then. In particular,
looking up the default email can die if getpwuid() fails,
but there are other errors that should take precedence.
Commit 734c7789a (ident: check for useConfigOnly before
auto-detection of name/email, 2016-03-30) reordered the
checks so that we prefer the error message for
useConfigOnly.

Instead, we can observe that while the name-handling depends
on "email" being set, the reverse is not true. So we can
simply set up the email variable first.

This does mean that if both are bogus, we'll complain about
the email before the name. But between the two, there is no
reason to prefer one over the other.

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

ident: mark error messages for translationJeff King Thu, 23 Feb 2017 08:12:30 +0000 (03:12 -0500)

ident: mark error messages for translation

We already translate the big "please tell me who you are"
hint, but missed the individual error messages that go with
it.

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

upload-pack: report "not our ref" to clientJonathan Tan Thu, 23 Feb 2017 18:43:03 +0000 (10:43 -0800)

upload-pack: report "not our ref" to client

Make upload-pack report "not our ref" errors to the client as an "ERR" line.
(If not, the client would be left waiting for a response when the server is
already dead.)

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: restrict auth methods to what the server advertisesJeff King Wed, 22 Feb 2017 23:34:37 +0000 (18:34 -0500)

http: restrict auth methods to what the server advertises

By default, we tell curl to use CURLAUTH_ANY, which does not
limit its set of auth methods. However, this results in an
extra round-trip to the server when authentication is
required. After we've fed the credential to curl, it wants
to probe the server to find its list of available methods
before sending an Authorization header.

We can shortcut this by limiting our http_auth_methods by
what the server told us it supports. In some cases (such as
when the server only supports Basic), that lets curl skip
the extra probe request.

The end result should look the same to the user, but you can
use GIT_TRACE_CURL to verify the sequence of requests:

GIT_TRACE_CURL=1 \
git ls-remote https://example.com/repo.git \
2>&1 >/dev/null |
egrep '(Send|Recv) header: (GET|HTTP|Auth)'

Before this patch, hitting a Basic-only server like
github.com results in:

Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
Recv header: HTTP/1.1 401 Authorization Required
Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
Recv header: HTTP/1.1 401 Authorization Required
Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
Send header: Authorization: Basic <redacted>
Recv header: HTTP/1.1 200 OK

And after:

Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
Recv header: HTTP/1.1 401 Authorization Required
Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
Send header: Authorization: Basic <redacted>
Recv header: HTTP/1.1 200 OK

The possible downsides are:

- This only helps for a Basic-only server; for a server
with multiple auth options, curl may still send a probe
request to see which ones are available (IOW, there's no
way to say "don't probe, I already know what the server
will say").

- The http_auth_methods variable is global, so this will
apply to all further requests. That's acceptable for
Git's usage of curl, though, which also treats the
credentials as global. I.e., in any given program
invocation we hit only one conceptual server (we may be
redirected at the outset, but in that case that's whose
auth_avail field we'd see).

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

l10n: pt_PT: update Portuguese tranlationVasco Almeida Sun, 5 Feb 2017 18:43:34 +0000 (17:43 -0100)

l10n: pt_PT: update Portuguese tranlation

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

git add -i: replace \t with blanks in the help messageRalf Thielow Wed, 22 Feb 2017 18:46:27 +0000 (19:46 +0100)

git add -i: replace \t with blanks in the help message

Within the help message of 'git add -i', the 'diff' command uses one
tab character and blanks to create the space between the name and the
description while the others use blanks only. So if the tab size is
not at 4 characters, this description will not be in range.
Replace the tab character with blanks.

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

Documentation: use brackets for optional argumentsbrian m. carlson Wed, 22 Feb 2017 12:25:46 +0000 (12:25 +0000)

Documentation: use brackets for optional arguments

The documentation for git blame used vertical bars for optional
arguments to -M and -C, which is unusual and potentially confusing.
Since most man pages use brackets for optional items, and that's
consistent with how we document the same options for git diff and
friends, use brackets here, too.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: correctly spell git worktree --detachbrian m. carlson Wed, 22 Feb 2017 12:34:42 +0000 (12:34 +0000)

Documentation: correctly spell git worktree --detach

The option is “--detach”, but we accidentally spelled it “--detached” at
one point in the man page.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Reported-by: Casey Rodarmor <casey@rodarmor.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: ignore failure to remove missing branch.<name... Ross Lagerwall Sat, 18 Feb 2017 00:23:41 +0000 (00:23 +0000)

remote: ignore failure to remove missing branch.<name>.merge

It is not all too unusual for a branch to use "branch.<name>.remote"
without "branch.<name>.merge". You may be using the 'push.default'
configuration set to 'current', for example, and do

$ git checkout -b side colleague/side
$ git config branch.side.remote colleague

However, "git remote rm" to remove the remote used in such a manner
fails with

"fatal: could not unset 'branch.<name>.merge'"

because it assumes that a branch that has .remote defined must also
have .merge defined. Detect the "cannot unset because it is not set
to begin with" case and ignore it.

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

git-check-ref-format: clarify documentation for --normalizeDamien Regad Sun, 19 Feb 2017 22:32:32 +0000 (23:32 +0100)

git-check-ref-format: clarify documentation for --normalize

Use of 'iff' may be confusing to people not familiar with this term.

Improving the --normalize option's documentation to remove the use of
'iff', and clearly describe what happens when the condition is not met.

Signed-off-by: Damien Regad <dregad@mantisbt.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://github.com/nafmo/git... Jiang Xin Tue, 21 Feb 2017 16:06:44 +0000 (00:06 +0800)

Merge branch 'master' of git://github.com/nafmo/git-l10n-sv

* 'master' of git://github.com/nafmo/git-l10n-sv:
l10n: sv.po: Update Swedish translation (3139t0f0u)

Merge branch 'svn-escape-backslash' of git://bogomips... Junio C Hamano Tue, 21 Feb 2017 06:01:59 +0000 (22:01 -0800)

Merge branch 'svn-escape-backslash' of git://bogomips.org/git-svn

* 'svn-escape-backslash' of git://bogomips.org/git-svn:
git-svn: escape backslashes in refnames

l10n: sv.po: Update Swedish translation (3139t0f0u)Peter Krefting Mon, 20 Feb 2017 18:40:11 +0000 (19:40 +0100)

l10n: sv.po: Update Swedish translation (3139t0f0u)

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

l10n: de.po: translate 241 messagesRalf Thielow Mon, 20 Feb 2017 17:40:36 +0000 (18:40 +0100)

l10n: de.po: translate 241 messages

Translate 241 messages came from git.pot update in 673bfad09
(l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed)) and a4d94835a
(l10n: git.pot: v2.12.0 round 2 (2 new)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Phillip Sz <phillip.szelat@gmail.com>

Merge branch 'ko/merge-l10n' of https://github.com... Jiang Xin Sun, 19 Feb 2017 14:08:05 +0000 (22:08 +0800)

Merge branch 'ko/merge-l10n' of https://github.com/changwoo/git-l10n-ko

* 'ko/merge-l10n' of https://github.com/changwoo/git-l10n-ko:
l10n: ko.po: Update Korean translation

Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin Sun, 19 Feb 2017 14:04:41 +0000 (22:04 +0800)

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
l10n: vi.po (3139t): Updated 2 new messages for rc1

l10n: ko.po: Update Korean translationChangwoo Ryu Sun, 19 Feb 2017 10:34:24 +0000 (19:34 +0900)

l10n: ko.po: Update Korean translation

Signed-off-by: Changwoo Ryu <cwryu@debian.org>

l10n: vi.po (3139t): Updated 2 new messages for rc1Tran Ngoc Quan Sat, 18 Feb 2017 00:18:54 +0000 (07:18 +0700)

l10n: vi.po (3139t): Updated 2 new messages for rc1

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

init: document dotfiles exclusion on template copyGrégoire Paris Fri, 17 Feb 2017 23:37:00 +0000 (00:37 +0100)

init: document dotfiles exclusion on template copy

Not just . and .., but any path that begins with dot is not copied
when copying the template directory to a new repository. You can
customize the template directory, copying some dotfiles might make
sense, but it's actually a good thing not to, because you would not
want to have your git directory copied in every git directory that
is created should you decide to put your template directory under
version control, for example. Plus, it might be used as a feature
by people who would want to exclude some files.

Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: fr.po: v2.12.0 round 2 3139tJean-Noel Avila Fri, 17 Feb 2017 23:10:04 +0000 (00:10 +0100)

l10n: fr.po: v2.12.0 round 2 3139t

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

tempfile: set errno to a known value before calling... Jeff King Fri, 17 Feb 2017 21:07:49 +0000 (16:07 -0500)

tempfile: set errno to a known value before calling ferror()

In close_tempfile(), we return an error if ferror()
indicated a previous failure, or if fclose() failed. In the
latter case, errno is set and it is useful for callers to
report it.

However, if _only_ ferror() triggers, then the value of
errno is based on whatever syscall happened to last fail,
which may not be related to our filehandle at all. A caller
cannot tell the difference between the two cases, and may
use "die_errno()" or similar to report a nonsense errno value.

One solution would be to actually pass back separate return
values for the two cases, so a caller can write a more
appropriate message for each case. But that makes the
interface clunky.

Instead, let's just set errno to the generic EIO in this case.
That's not as descriptive as we'd like, but at least it's
predictable. So it's better than the status quo in all cases
but one: when the last syscall really did involve a failure
on our filehandle, we'll be wiping that out. But that's a
fragile thing for us to rely on.

In any case, we'll let the errno result from fclose() take
precedence over our value, as we know that's recent and
accurate (and many I/O errors will persist through the
fclose anyway).

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

Git 2.12-rc2 v2.12.0-rc2Junio C Hamano Fri, 17 Feb 2017 22:00:19 +0000 (14:00 -0800)

Git 2.12-rc2

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

l10n: git.pot: v2.12.0 round 2 (2 new)Jiang Xin Fri, 17 Feb 2017 17:00:54 +0000 (01:00 +0800)

l10n: git.pot: v2.12.0 round 2 (2 new)

Generate po/git.pot from v2.12.0-rc1 for git v2.12.0 l10n round 2.

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

Merge branch 'master' of git://github.com/git-l10n... Jiang Xin Fri, 17 Feb 2017 16:59:51 +0000 (00:59 +0800)

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

* 'master' of git://github.com/git-l10n/git-po:
l10n: vi.po: Updated Vietnamese translation (3137t)
l10n: update Catalan translation
l10n: sv.po: Update Swedish translation (3137t0f0u)
l10n: fr.po: v2.11-rc0 first round
l10n: ko.po: Update Korean translation
l10n: fr.po: Fix a typo in the French translation
l10n: fr.po: Remove gender specific adjectives
l10n: fr.po: Fix typos
l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed)
l10n: bg: Updated Bulgarian translation (2913t+0f+0u)
l10n: fixes to Catalan translation
l10n: zh_CN: review for git v2.11.0 l10n
l10n: New Catalan translation maintainer