1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00
Commit graph

51200 commits

Author SHA1 Message Date
Johannes Schindelin
8032cc4462 config: introduce an optional event stream while parsing
This extends our config parser so that it can optionally produce an event
stream via callback function, where it reports e.g. when a comment was
parsed, or a section header, etc.

This parser will be used subsequently to handle the scenarios better where
removing config entries would make sections empty, or where a new entry
could be added to an already-existing, empty section.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 21:32:59 +09:00
Johannes Schindelin
b73bdc34c0 t1300: --unset-all can leave an empty section behind (bug)
We already have a test demonstrating that removing the last entry from a
config section fails to remove the section header of the now-empty
section.

The same can happen, of course, if we remove the last entries in one fell
swoop. This is *also* a bug, and should be fixed at the same time.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 21:32:58 +09:00
Johannes Schindelin
422e8ef26d t1300: add a few more hairy examples of sections becoming empty
During the review of the first iteration of the patch series to remove
sections that become empty upon --unset or --unset-all, Jeff King
identified a couple of problematic cases with the backtracking approach
that was still used then to "look backwards for the section header":
https://public-inbox.org/git/20180329213229.GG2939@sigill.intra.peff.net/

This patch adds a couple of concocted examples designed to fool a
backtracking parser.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 21:32:58 +09:00
Eric Sunshine
249482daf0 configure.ac: fix botched FREAD_READS_DIRECTORIES check
3adf9fdecf (configure.ac: loosen FREAD_READS_DIRECTORIES test program,
2017-06-14) broke the test program for the FREAD_READS_DIRECTORIES check
by making it syntactically invalid (a dangling ")") and by botching the
type returned from 'main' (a FILE* rather than int). As a consequence,
the test program won't even compile, thus the check fails
unconditionally. Fix these problems.

Reported-by: Jonathan Primrose <jprimros@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 18:50:35 +09:00
Eric Sunshine
22d11a6e8e git-worktree.txt: unify command-line prompt in example blocks
The command-line prompt in the "EXAMPLES" section is "$", however,
examples in the 'git worktree list' section (oddly) use "S" as a
prompt. Fix this inconsistency by settling on "$" as prompt in all
examples.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 18:49:24 +09:00
Eric Sunshine
3f0b42bd07 git-worktree.txt: recommend 'git worktree remove' over manual deletion
When cc73385cf6 (worktree remove: new command, 2018-02-12) implemented
and documented 'git worktree remove', it forgot to update existing
instructions suggesting manual deletion. Fix this oversight by
recommending 'git worktree remove' instead.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 18:49:22 +09:00
Elijah Newren
8523b1e355 Documentation: normalize spelling of 'normalised'
This could be a localization issue, but we had about four dozen
"normalize"s (or variants, e.g. normalized, renormalize, etc.), and only
one "normalised" (no other variants), so normalize normalised into
normalized.

Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 14:15:07 +09:00
Elijah Newren
c30d4f1b84 Documentation: fix several one-character-off spelling errors
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 14:15:02 +09:00
Paul-Sebastian Ungureanu
decf711fc1 t/helper: 'test-chmtime (--get|-g)' to print only the mtime
Compared to 'test-chmtime -v +0 file' which prints the mtime and
and the file name, 'test-chmtime --get file' displays only the mtime.
If it is used in combination with (+|=|=+|=-|-)seconds, it changes
and prints the new value.

	test-chmtime -v +0 file | sed 's/[^0-9].*$//'

is now equivalent to:

	test-chmtime --get file

Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 11:33:19 +09:00
Lucas Werkmeister
e67d906d73 daemon.c: fix condition for redirecting stderr
Since the --log-destination option was added in 0c591cacb ("daemon: add
--log-destination=(stderr|syslog|none)", 2018-02-04) with the explicit
goal of allowing logging to stderr when running in inetd mode, we should
not always redirect stderr to /dev/null in inetd mode, but rather only
when stderr is not being used for logging.

Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 11:25:48 +09:00
Johannes Schindelin
43b44ccfe7 t5404: relax overzealous test
In 0b294c0abf (make deleting a missing ref more quiet, 2008-07-08), we
added a test to verify that deleting an already-deleted ref does not
show an error.

Our test simply looks for the substring 'error' in the output of the
`git push`, which might look innocuous on the face of it.

Suppose, however, that you are a big fan of whales. Or even better: your
IT administrator has a whale of a time picking cute user names, e.g.
referring to you (due to your like of India Pale Ales) as "one of the
cuter rorquals" (see https://en.wikipedia.org/wiki/Rorqual to learn a
thing or two about rorquals) and hence your home directory becomes
/home/cuterrorqual. If you now run t5404, it fails! Why? Because the
test calls `git push origin :b3` which outputs:

    To /home/cuterrorqual/git/t/trash directory.t5404-tracking-branches/.
     - [deleted]         b3

Note how there is no error displayed in that output? But of course
"error" is a substring of "cuterrorqual". And so that `grep error
output` finds something.

This bug was not, actually, caught having "error" as a substring of the
user name but while working in a worktree called "colorize-push-errors",
whose name was part of that output, too, suggesting that not even
testing for the *word* `error` via `git grep -w error output` would fix
the underlying issue.

This patch chooses instead to look for the prefix "error:" at the
beginning of the line, so that there can be no ambiguity that any catch
was indeed a message generated by Git's `error_builtin()` function.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 11:17:16 +09:00
Ævar Arnfjörð Bjarmason
51db271587 git-svn: avoid warning on undef readline()
Change code in Git.pm that sometimes calls chomp() on undef to only do
so the value is defined.

This code has been chomping undef values ever since it was added in
b26098fc2f ("git-svn: reduce scope of input record separator change",
2016-10-14), but started warning due to the introduction of "use
warnings" to Git.pm in my f0e19cb7ce ("Git.pm: add the "use warnings"
pragma", 2018-02-25) released with 2.17.0.

Since this function will return undef in those cases it's still
possible that the code using it will warn if it does a chomp of its
own, as the code added in b26098fc2f ("git-svn: reduce scope of input
record separator change", 2016-10-14) might do, but since git-svn has
"use warnings" already that's clearly not a codepath that's going to
warn.

See https://public-inbox.org/git/86h8oobl36.fsf@phe.ftfl.ca/ for the
original report.

Reported-by: Joseph Mingrone <jrm@ftfl.ca>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Improved-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 11:11:13 +09:00
Harald Nordgren
1fb20dfd8e ls-remote: create '--sort' option
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 10:51:56 +09:00
Jeff King
427cbc9dbf ref-filter: factor ref_array pushing into its own function
In preparation for callers constructing their own ref_array
structs, let's move our own internal push operation into its
own function.

While we're at it, we can replace REALLOC_ARRAY() with
ALLOC_GROW(), which should give the growth operation
amortized linear complexity (as opposed to growing by one,
which is potentially quadratic, though in-place realloc
growth often makes this faster in practice).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 06:14:46 +09:00
Jeff King
0ffaa00f45 ref-filter: make ref_array_item allocation more consistent
We have a helper function to allocate ref_array_item
structs, but it only takes a subset of the possible fields
in the struct as initializers. We could have it accept an
argument for _every_ field, but that becomes a pain for the
fields which some callers don't want to set initially.

Instead, let's be explicit that it takes only the minimum
required to create the ref, and that callers should then
fill in the rest themselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 06:14:45 +09:00
Jeff King
53df97a29d ref-filter: use "struct object_id" consistently
Internally we store a "struct object_id", and all of our
callers have one to pass us. But we insist that they peel it
to its bare-sha1 hash, which we then hashcpy() into place.
Let's pass it around as an object_id, which future-proofs us
for a post-sha1 world.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 06:14:45 +09:00
Michal Nazarewicz
4855f06fb3 send-email: simplify Gmail example in the documentation
There is no need for use to manually call ‘git credential’ especially
as the interface isn’t super user-friendly and a bit confusing.  ‘git
send-email’ will do that for them at the first execution and if the
password matches, it will be saved in the store.

Simplify the documentaion so it dosn’t include the ‘git credential’
invocation (which was incorrect anyway as it should use ‘approve’
instead of ‘fill’) and instead just mentions that credentials helper
must be set up.

Signed-off-by: Michał Nazarewicz <mina86@mina86.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-08 11:42:57 +09:00
Anders Kaseorg
bbd374dd20 Documentation/git-bisect.txt: git bisect term → git bisect terms
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-07 20:50:19 +09:00
Johannes Schindelin
dde154b5bd t1300: remove unreasonable expectation from TODO
In https://public-inbox.org/git/7vvc8alzat.fsf@alter.siamese.dyndns.org/
a reasonable patch was made quite a bit less so by changing a test case
demonstrating a bug to a test case that demonstrates that we ask for too
much: the test case 'unsetting the last key in a section removes header'
now expects a future bug fix to be able to determine whether a free-form
comment above a section header refers to said section or not.

Rather than shooting for the stars (and not even getting off the
ground), let's start shooting for something obtainable and be reasonably
confident that we *can* get it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Johannes Schindelin
85bf5d61e7 t1300: avoid relying on a bug
The test case 'unset with cont. lines' relied on a bug that is about to
be fixed: it tests *explicitly* that removing the last entry from a
config section leaves an *empty* section behind.

Let's fix this test case not to rely on that behavior, simply by
preventing the section from becoming empty.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Johannes Schindelin
46fc89ce74 config --replace-all: avoid extra line breaks
When replacing multiple config entries at once, we did not re-set the
flag that indicates whether we need to insert a new-line before the new
entry. As a consequence, an extra new-line was inserted under certain
circumstances.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Johannes Schindelin
e9313952bf t1300: demonstrate that --replace-all can "invent" newlines
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Johannes Schindelin
efbaca1b69 t1300: rename it to reflect that repo-config was deprecated
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Johannes Schindelin
83b7fd8771 git_config_set: fix off-by-two
Currently, we are slightly overzealous When removing an entry from a
config file of this form:

	[abc]a
	[xyz]
		key = value

When calling `git config --unset abc.a` on this file, it leaves this
(invalid) config behind:

	[
	[xyz]
		key = value

The reason is that we try to search for the beginning of the line (or
for the end of the preceding section header on the same line) that
defines abc.a, but as an optimization, we subtract 2 from the offset
pointing just after the definition before we call
find_beginning_of_line(). That function, however, *also* performs that
optimization and promptly fails to find the section header correctly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:30:03 +09:00
Bill Ritcher
6ceb658c99 mergetools: add support for guiffy
Add guiffy as difftool and mergetool

guiffy is available on Windows, Linux, and MacOS

Signed-off-by: Bill Ritcher <Bill_Ritcher@guiffy.com>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 08:11:39 +09:00
Andreas Heiduk
cb427e9eb0 git-svn: allow empty email-address using authors-prog and authors-file
The email address in --authors-file and --authors-prog can be empty but
git-svn translated it into a fictional email address in the form

	jondoe <jondoe@6aafaa21e0fb4338a68ab372a049893d>

containing the SVN repository UUID. Now git-svn behaves like git-commit:
If the email is *explicitly* set to the empty string using '<>', the
commit does not contain an email address, only the name:

	jondoe <>

Allowing to remove the email address *intentionally* prevents automatic
systems from sending emails to those fictional addresses and avoids
cluttering the log output with unnecessary stuff.

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
Signed-off-by: Eric Wong <e@80x24.org>
2018-04-05 19:22:06 +00:00
Brandon Williams
86238e07ef commit: allow partial commits with relative paths
Commit 8894d53580 (commit: allow partial commits with relative paths,
2011-07-30) ensured that partial commits were allowed when a user
supplies a relative pathspec but then this was regressed in 5879f5684c
(remove prefix argument from pathspec_prefix, 2011-09-04) when the
prefix argument to 'pathspec_prefix' removed and the 'list_paths'
function wasn't properly adjusted to cope with the change, resulting in
over-eager pruning of the tree that is overlayed on the index.

This fixes the regression and adds a regression test so this can be
prevented in the future.

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 17:05:48 +09:00
Jeff King
e9184b0789 t5561: skip tests if curl is not available
It's possible to have libcurl installed but not the curl
command-line utility. The latter is not generally needed for
Git's http support, but we use it in t5561 for basic tests
of http-backend's functionality. Let's detect when it's
missing and skip this test.

Note that we can't mark the individual tests with the CURL
prerequisite. They're in a shared t556x_common that uses the
GET and POST functions as a level of indirection, and it's
only our implementations of those functions in t5561 that
requires curl. It's not a problem, though, as literally
every test in the script would depend on the prerequisite
anyway.

Reported-by: Jens Krüger <Jens.Krueger@frm2.tum.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 16:21:41 +09:00
Jeff King
fcd9d7096f t5561: drop curl stderr redirects
For a normal test run, stderr is already redirected to
/dev/null by the test suite. When used with "-v",
suppressing stderr is actively harmful, as it may hide the
reason for curl failing.

Reported-by: Jens Krüger <Jens.Krueger@frm2.tum.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 16:21:39 +09:00
Eric Sunshine
b1801b85a3 t2028: tighten grep expression to make "move worktree" test more robust
Following a rename of worktree "source" to "destination", the "move
worktree" test uses grep to verify that the output of "git worktree list
--porcelain" does not contain "source" (and does contain "destination").
Unfortunately, the grep expression is too loose and can match
unexpectedly. For example, if component of the test trash directory path
matches "source" (e.g. "/home/me/sources/git/t/trash*"), then the test
will be fooled into thinking that "source" still exists. Tighten the
expression to avoid such accidental matches.

While at it, drop an unused variable ("toplevel") from the test and
tighten a similarly too-loose expression in a related test.

Reported-by: Jens Krüger <Jens.Krueger@frm2.tum.de>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 16:08:33 +09:00
Eric Sunshine
1f537be3f2 t3200: verify "branch --list" sanity when rebasing from detached HEAD
"git branch --list" shows an in-progress rebase as:

  * (no branch, rebasing <branch>)
    master
    ...

However, if the rebase is started from a detached HEAD, then there is no
<branch>, and it would attempt to print a NULL pointer. The previous
commit fixed this problem, so add a test to verify that the output is
sane in this situation.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 16:05:09 +09:00
Kaartic Sivaraam
a236f900d8 branch --list: print useful info whilst interactive rebasing a detached HEAD
When rebasing interactively (rebase -i), "git branch --list" prints
a line indicating the current branch being rebased. This works well
when the interactive rebase is initiated when a local branch is
checked out.

This doesn't play well when the rebase is initiated on a detached
HEAD. When "git branch --list" tries to print information related
to the interactive rebase in this case it tries to print the name
of a branch using an uninitialized variable and thus tries to
print a "null pointer string". As a consequence, it does not provide
useful information while also inducing undefined behaviour.

So, print the point from which the rebase was started when interactive
rebasing a detached HEAD.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05 16:01:35 +09:00
Andreas Heiduk
9c18398f8b git-svn: search --authors-prog in PATH too
In 36db1eddf9 ("git-svn: add --authors-prog option", 2009-05-14) the path
to authors-prog was made absolute because git-svn changes the current
directory in some situations. This makes sense if the program is part of
the repository but prevents searching via $PATH.

The old behaviour is still retained, but if the file does not exists, then
authors-prog is searched for in $PATH as any other command.

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
Signed-off-by: Eric Wong <e@80x24.org>
2018-04-05 06:55:02 +00:00
Derrick Stolee
f237c8b6fe commit-graph: implement git-commit-graph write
Teach git-commit-graph to write graph files. Create new test script to verify
this command succeeds without failure.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:38 -07:00
Derrick Stolee
08fd81c9b6 commit-graph: implement write_commit_graph()
Teach Git to write a commit graph file by checking all packed objects
to see if they are commits, then store the file in the given object
directory.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:38 -07:00
Derrick Stolee
4ce58ee38d commit-graph: create git-commit-graph builtin
Teach git the 'commit-graph' builtin that will be used for writing and
reading packed graph files. The current implementation is mostly
empty, except for an '--object-dir' option.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:38 -07:00
Derrick Stolee
ae30d7b115 graph: add commit graph design document
Add Documentation/technical/commit-graph.txt with details of the planned
commit graph feature, including future plans.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:31 -07:00
Derrick Stolee
b84f767c8a commit-graph: add format document
Add document specifying the binary format for commit graphs. This
format allows for:

* New versions.
* New hash functions and hash lengths.
* Optional extensions.

Basic header information is followed by a binary table of contents
into "chunks" that include:

* An ordered list of commit object IDs.
* A 256-entry fanout into that list of OIDs.
* A list of metadata for the commits.
* A list of "large edges" to enable octopus merges.

The format automatically includes two parent positions for every
commit. This favors speed over space, since using only one position
per commit would cause an extra level of indirection for every merge
commit. (Octopus merges suffer from this indirection, but they are
very rare.)

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:31 -07:00
Derrick Stolee
cfe83216e4 csum-file: refactor finalize_hashfile() method
If we want to use a hashfile on the temporary file for a lockfile, then
we need finalize_hashfile() to fully write the trailing hash but also keep
the file descriptor open.

Do this by adding a new CSUM_HASH_IN_STREAM flag along with a functional
change that checks this flag before writing the checksum to the stream.
This differs from previous behavior since it would be written if either
CSUM_CLOSE or CSUM_FSYNC is provided.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:30 -07:00
Derrick Stolee
f2af9f5e02 csum-file: rename hashclose() to finalize_hashfile()
The hashclose() method behaves very differently depending on the flags
parameter. In particular, the file descriptor is not always closed.

Perform a simple rename of "hashclose()" to "finalize_hashfile()" in
preparation for functional changes.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 14:27:30 -07:00
Junio C Hamano
468165c1d8 Git 2.17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-02 10:13:35 -07:00
Junio C Hamano
1614dd0fbc l10n for Git 2.17.0 round 1
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJawLbqAAoJEMek6Rt1RHoou0AP/RKpAATgtMBPprgvwbMoJ1Mu
 Q1Lh56tRweg8ZjbXTJkRL15vRZNYwv3j+hM8H5wc7HHf8QFTYfQNK9KjWH5vyD5a
 ZR/akqdpVugiHt1mdCSRbp/A+qoj8mpX0SRTMqzYNX0BiZSb31ScShy1bCTY/BJl
 rmyWwmFtdgrzOrhDCYKVcoruRD1B13ZBvxmlcXrUiGuC5EwVHwR5GCcrG4hWILyq
 2MblmVrJU1liA9q0F8rBkTZYTk4rMo9g/Tz+xZvCVUTttwVvvMUA4V680ECIHL30
 wiip1nAhEBDGL9RyB4aOlNu75fzY6RJ8KL/yBBwG4FfckQ0LIQg5f3UecqV2gAdx
 P+LA70hU+0FguVn2GtOJZWg1m/adnc3aovp1wxQlUOmp+TiaOPmTl8CRdMxgu8dz
 O8hnorvTP9MFCySkJ0QB2ZkFJU9+szgF0AqoxT627byAv6/ROSLYUxAbOnUoboxL
 ec09C/vzSj6qkP6I+CX/hZBeFAqTN2j9CnJwXhm/niArkH+yTVQ/JBSesjygVvu0
 NilepolgTpfSpGQEJvIQOIHMQbueP3XII0YJE3oDn5vWl/ZYaCVXhyTAlElmP/pa
 lttgIYJ8bK2zJGspLN/FydGXCgOTr9OoE/202q1CaHKeRhKTVC4RuBpoei+ik9SZ
 xVBykNEymi5S0CRUeJlP
 =xKC7
 -----END PGP SIGNATURE-----

Merge tag 'l10n-2.17.0-rnd1' of git://github.com/git-l10n/git-po

l10n for Git 2.17.0 round 1

* tag 'l10n-2.17.0-rnd1' of git://github.com/git-l10n/git-po:
  l10n: de.po: translate 132 new messages
  l10n: zh_CN: review for git v2.17.0 l10n round 1
  l10n: zh_CN: for git v2.17.0 l10n round 1
  l10n: ko.po: Update Korean translation
  l10n: fr.po: v2.17.0 no fuzzy
  l10n: sv.po: Update Swedish translation (3376t0f0u)
  l10n: Update Catalan translation
  l10n: fr.po v2.17.0 round 1
  l10n: vi.po(3376t): Updated Vietnamese translation for v2.17
  l10n: bg.po: Updated Bulgarian translation (3376t)
  l10n: es.po: Update Spanish translation 2.17.0
  l10n: git.pot: v2.17.0 round 1 (132 new, 44 removed)
  l10n: es.po: fixes to Spanish translation
2018-04-02 10:12:38 -07:00
Junio C Hamano
5f9441769f Merge branch 'pw/add-p-single'
Hotfix.

* pw/add-p-single:
  add -p: fix 2.17.0-rc* regression due to moved code
2018-04-02 10:10:55 -07:00
Ævar Arnfjörð Bjarmason
fd2fb4aa0c add -p: fix 2.17.0-rc* regression due to moved code
Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if
there's more than one hunk", 2018-02-13) which is present in
2.17.0-rc*, but not 2.16.0.

In Perl, regex variables like $1 always refer to the last regex
match. When the aforementioned change added a new regex match between
the old match and the corresponding code that was expecting $1, the $1
variable would always be undef, since the newly inserted regex match
doesn't have any captures.

As a result the "/" feature to search for a string in a hunk by regex
completely broke, on git.git:

    $ perl -pi -e 's/Git/Tig/g' README.md
    $ ./git --exec-path=$PWD add -p
    [..]
    Stage this hunk [y,n,q,a,d,j,J,g,/,s,e,?]? s
    Split into 4 hunks.
    [...]
    Stage this hunk [y,n,q,a,d,j,J,g,/,s,e,?]? /Many
    Use of uninitialized value $1 in string eq at /home/avar/g/git/git-add--interactive line 1568, <STDIN> line 1.
    search for regex? Many

I.e. the initial "/regex" command wouldn't work, and would always emit
a warning and ask again for a regex, now it works as intended again.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-31 21:54:28 -07:00
Ralf Thielow
8bb6d60dd6 l10n: de.po: translate 132 new messages
Translate 132 new messages came from git.pot update in abc8de64d (l10n:
git.pot: v2.17.0 round 1 (132 new, 44 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2018-03-31 13:21:09 +02:00
Jeff King
05e293c1ac config: move flockfile() closer to unlocked functions
Commit 260d408e32 (config: use getc_unlocked when reading
from file, 2015-04-16) taught git_config_from_file() to lock
the filehandle so that we could safely use the faster
unlocked functions to access the handle.

However, it split the logic into two places:

  1. The master lock/unlock happens in git_config_from_file().

  2. The decision to use the unlocked functions happens in
     do_config_from_file().

That means that if anybody calls the latter function, they
will accidentally use the unlocked functions without holding
the lock. And indeed, git_config_from_stdin() does so.

In practice, this hasn't been a problem since this code
isn't generally multi-threaded (and even if some Git program
happened to have another thread running, it's unlikely to be
reading from stdin). But it's a good practice to make sure
we're always holding the lock before using the unlocked
functions.

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>
2018-03-30 12:52:46 -07:00
Jeff King
fb9c2d2703 refs: use chdir_notify to update cached relative paths
Commit f57f37e2e1 (files-backend: remove the use of
git_path(), 2017-03-26) introduced a regression when a
relative $GIT_DIR is used in a working tree:

  - when we initialize the ref backend, we make a copy of
    get_git_dir(), which may be relative

  - later, we may call setup_work_tree() and chdir to the
    root of the working tree

  - further calls to the ref code will use the stored git
    directory, but relative paths will now point to the
    wrong place

The new test in t1501 demonstrates one such instance (the
bug causes us to write the ref update to the nonsense
"relative/relative/.git").

Since setup_work_tree() now uses chdir_notify, we can just
ask it update our relative paths when necessary.

Reported-by: Rafael Ascensao <rafa.almas@gmail.com>
Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-30 12:50:03 -07:00
Jeff King
8500e0de3f set_work_tree: use chdir_notify
When we change to the top of the working tree, we manually
re-adjust $GIT_DIR and call set_git_dir() again, in order to
update any relative git-dir we'd compute earlier.

Instead of the work-tree code having to know to call the
git-dir code, let's use the new chdir_notify interface.
There are two spots that need updating, with a few
subtleties in each:

  1. the set_git_dir() code needs to chdir_notify_register()
     so it can be told when to update its path.

     Technically we could push this down into repo_set_gitdir(),
     so that even repository structs besides the_repository
     could benefit from this. But that opens up a lot of
     complications:

      - we'd still need to touch set_git_dir(), because it
        does some other setup (like setting $GIT_DIR in the
        environment)

      - submodules using other repository structs get
        cleaned up, which means we'd need to remove them
        from the chdir_notify list

      - it's unlikely to fix any bugs, since we shouldn't
        generally chdir() in the middle of working on a
        submodule

  2. setup_work_tree now needs to call chdir_notify(), and
     can lose its manual set_git_dir() call.

     Note that at first glance it looks like this undoes the
     absolute-to-relative optimization added by 044bbbcb63
     (Make git_dir a path relative to work_tree in
     setup_work_tree(), 2008-06-19). But for the most part
     that optimization was just _undoing_ the
     relative-to-absolute conversion which the function was
     doing earlier (and which is now gone).

     It is true that if you already have an absolute git_dir
     that the setup_work_tree() function will no longer make
     it relative as a side effect. But:

       - we generally do have relative git-dir's due to the
         way the discovery code works

       - if we really care about making git-dir's relative
         when possible, then we should be relativizing them
         earlier (e.g., when we see an absolute $GIT_DIR we
         could turn it relative, whether we are going to
         chdir into a worktree or not). That would cover all
         cases, including ones that 044bbbcb63 did not.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-30 12:49:57 -07:00
Jeff King
2b5ed37365 add chdir-notify API
If one part of the code does a permanent chdir(), then this
invalidates any relative paths that may be held by other
parts of the code. For example, setup_work_tree() moves us
to the top of the working tree, which may invalidate a
previously stored relative gitdir.

We've hacked around this case by teaching setup_work_tree()
to re-run set_git_dir() with an adjusted path, but this
stomps all over the idea of module boundaries.
setup_work_tree() shouldn't have to know all of the places
that need to be fed an adjusted path. And indeed, there's at
least one other place (the refs code) which needs adjusting.

Let's provide an API to let code that stores relative paths
"subscribe" to updates to the current working directory.
This means that callers of chdir() don't need to know about
all subscribers ahead of time; they can simply consult a
dynamically built list.

Note that our helper function to reparent relative paths
uses the simple remove_leading_path(). We could in theory
use the much smarter relative_path(), but that led to some
problems as described in 41894ae3a3 (Use simpler
relative_path when set_git_dir, 2013-10-14). Since we're
aiming to replace the setup_work_tree() code here, let's
follow its lead.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-30 12:49:57 -07:00
Nguyễn Thái Ngọc Duy
cb50761959 trace.c: export trace_setup_key
This is so that we can print traces based on this key outside trace.c.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-30 12:49:57 -07:00