Commit graph

57355 commits

Author SHA1 Message Date
Jiang Xin 468d356a81 Git 2.24-rc1
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE4fA2sf7nIh/HeOzvsLXohpav5ssFAl2xOfYACgkQsLXohpav
 5ss0lg//bIacUJToa4dfT7FHw/uG4x0hlwOEJ8Iul9TifIPCQsRM2lOQkCgde+Dd
 6nXu4HLIjCBpFcUmrfEPErOp8eqEshY4DJ6n7UadAxm+uUB7PWI4r7v24JJtFtyM
 VrrqlkhgiMo72h+KxTKNZeiY+s/aD7yGwU//2cGckTgr0H0qxt2+NrOeH3jYMQ1p
 NiSZK3xDKUUxIf3XmKn6GjAS5fXnBsfY2gIj7xg4mhyQDc3Ui+vHN6cr5qESYqa+
 O1CmZEzBxksxN0kDgF53bqry9zmRr1Z8Hfocqc9xVu43tObohS/PZ8T9bnTH97UJ
 tDBfRankgXbjoLyUmct+eYlm/23m8h0fKPxNT1XXoLsRxiouJgIg+iIj86QbsAm6
 rF1XYubiTUtKiMcmYMHK1vlXRPTUvkuJp/JhQyui5vdSE/Q7+uSp/4fLpdvgpE1H
 3NqFtYA+rkxR/cT8+ldL8iDw5Y5J4O6egwfzEB8ZYAsMLwFc7s/aM312srSt9EN+
 9j80WeUju3nuAQlhqhYMVERHm84WewcPD8AaBepFNfhJLmtVVCOovQEsc62gRnwW
 B27EXjKr+ASrMa7rg73RWiqC13gAh4c9kS8FUVZVHstRnGlO5dmiHTU6td+Id10r
 IV4i7pyFQA0/1IXd8O0J6F9iUvPTIOSqzVhywZIkDkRcXNQqOdg=
 =zfW8
 -----END PGP SIGNATURE-----

Merge tag 'v2.24.0-rc1' of github.com:git/git into master

Git 2.24-rc1

* tag 'v2.24.0-rc1' of github.com:git/git:
  Git 2.24-rc1
  repo-settings: read an int for index.version
  ci: fix GCC install in the Travis CI GCC OSX job
  Eleventh batch
  ci(osx): use new location of the `perforce` cask
  t7419: change test_must_fail to ! for grep
  t4014: make output-directory tests self-contained
  ci(visual-studio): actually run the tests in parallel
  ci(visual-studio): use strict compile flags, and optimization
  userdiff: fix some corner cases in dts regex
  test-progress: fix test failures on big-endian systems
  completion: clarify installation instruction for zsh
  grep: avoid leak of chartables in PCRE2
  grep: make PCRE2 aware of custom allocator
  grep: make PCRE1 aware of custom allocator
  remote-curl: pass on atomic capability to remote side
  diff-highlight: fix a whitespace nit
  fsmonitor: don't fill bitmap with entries to be removed
2019-10-28 13:18:55 +08:00
Johannes Schindelin 60e6569a12 mingw: avoid a buffer overrun in needs_hiding()
When this function is passed a path with a trailing slash, it runs right
over the end of that path.

Let's fix this.

Co-authored-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 12:38:51 +09:00
SZEDER Gábor 8b656572ca builtin/commit-graph.c: remove subcommand-less usage string
The first line in 'git commit-graph's usage string indicates that this
command can be invoked without specifying a subcommand.  However, this
is not the case:

  $ git commit-graph
  usage: git commit-graph [--object-dir <objdir>]
     or: git commit-graph read [--object-dir <objdir>]
  [...]
  $ echo $?
  129

Remove this line from the usage string.

The synopsis in the manpage doesn't contain this line.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 12:24:17 +09:00
brian m. carlson fa26d5ede6 t4048: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson cf02be8486 t4045: make hash-size independent
Replace a hard-coded all-zeros object ID with a use of $ZERO_OID.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 38ee26b2a3 t4044: update test to work with SHA-256
This test produces pseudo-collisions and tests git diff's behavior with
them, and is therefore sensitive to the hash in use. Update the test to
compute the collisions for both SHA-1 and SHA-256 using appropriate
constants. Move the heredocs inside the setup block so that all of the
setup code can be tested for failure.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 37ab8ebef1 t4039: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 0370b35414 t4038: abstract away SHA-1 specific constants
Compute several object IDs that exist in expected output, since we don't
care about the specific object IDs, only that the format of the output
is syntactically correct.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 0253e126a2 t4034: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.  Move some expected result heredocs around so
that they can use computed variables.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 45e2ef2b1d t4027: make hash-size independent
Instead of hard-coding the length of an object ID, look this value up
using the translation tables.  Similarly, compute input data for invalid
submodule entries using the tables as well.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 79b0edc1a0 t4015: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 840624ff55 t4011: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 32a6707267 t4010: abstract away SHA-1-specific constants
Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 440bf91dfa t3429: remove SHA1 annotation
This test passes successfully with SHA-256, so remove the annotation
which limits it to SHA-1.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 0b408ca2bd t1305: avoid comparing extensions
A repository using a hash other than SHA-1 will need to have an
extension in the config file.  Ignore any extensions when comparing
config files, since they don't usefully contribute to the goal of the
test.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:58 +09:00
brian m. carlson 2eabd38313 rev-parse: add a --show-object-format option
Add an option to print the object format used for input, output, or
storage. This allows shell scripts to discover the hash algorithm in
use.

Since the transition plan allows for multiple input algorithms, document
that we may provide multiple results for input, and the format that the
results may take. While we don't support this now, documenting it early
means that script authors can future-proof their scripts for when we do.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:34:57 +09:00
Robert Luberda 52bd3e4657 gitweb: correctly store previous rev in javascript-actions mode
Without this change, the setting

 $feature{'javascript-actions'}{'default'} = [1];

in gitweb.conf breaks gitweb's blame page: clicking on line numbers
displayed in the second column on the page has no effect.

For comparison, with javascript-actions disabled, clicking on line
numbers loads the previous version of the line.

Addresses https://bugs.debian.org/741883.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Robert Luberda <robert@debian.org>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28 11:06:57 +09:00
Prarit Bhargava 45e206f0d8 t4203: use test-lib.sh definitions
Use name and email definitions from test-lib.sh.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25 14:12:58 +09:00
Prarit Bhargava 2ae4944aac t6006: use test-lib.sh definitions
Use name and email definitions from test-lib.sh.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25 14:09:53 +09:00
Derrick Stolee cb99a34e23 commit-graph: fix writing first commit-graph during fetch
The previous commit includes a failing test for an issue around
fetch.writeCommitGraph and fetching in a repo with a submodule. Here, we
fix that bug and set the test to "test_expect_success".

The problem arises with this set of commands when the remote repo at
<url> has a submodule. Note that --recurse-submodules is not needed to
demonstrate the bug.

	$ git clone <url> test
	$ cd test
	$ git -c fetch.writeCommitGraph=true fetch origin
	Computing commit graph generation numbers: 100% (12/12), done.
	BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2>
	Aborted (core dumped)

As an initial fix, I converted the code in builtin/fetch.c that calls
write_commit_graph_reachable() to instead launch a "git commit-graph
write --reachable --split" process. That code worked, but is not how we
want the feature to work long-term.

That test did demonstrate that the issue must be something to do with
internal state of the 'git fetch' process.

The write_commit_graph() method in commit-graph.c ensures the commits we
plan to write are "closed under reachability" using close_reachable().
This method walks from the input commits, and uses the UNINTERESTING
flag to mark which commits have already been visited. This allows the
walk to take O(N) time, where N is the number of commits, instead of
O(P) time, where P is the number of paths. (The number of paths can be
exponential in the number of commits.)

However, the UNINTERESTING flag is used in lots of places in the
codebase. This flag usually means some barrier to stop a commit walk,
such as in revision-walking to compare histories. It is not often
cleared after the walk completes because the starting points of those
walks do not have the UNINTERESTING flag, and clear_commit_marks() would
stop immediately.

This is happening during a 'git fetch' call with a remote. The fetch
negotiation is comparing the remote refs with the local refs and marking
some commits as UNINTERESTING.

I tested running clear_commit_marks_many() to clear the UNINTERESTING
flag inside close_reachable(), but the tips did not have the flag, so
that did nothing.

It turns out that the calculate_changed_submodule_paths() method is at
fault. Thanks, Peff, for pointing out this detail! More specifically,
for each submodule, the collect_changed_submodules() runs a revision
walk to essentially do file-history on the list of submodules. That
revision walk marks commits UNININTERESTING if they are simplified away
by not changing the submodule.

Instead, I finally arrived on the conclusion that I should use a flag
that is not used in any other part of the code. In commit-reach.c, a
number of flags were defined for commit walk algorithms. The REACHABLE
flag seemed like it made the most sense, and it seems it was not
actually used in the file. The REACHABLE flag was used in early versions
of commit-reach.c, but was removed by 4fbcca4 (commit-reach: make
can_all_from_reach... linear, 2018-07-20).

Add the REACHABLE flag to commit-graph.c and use it instead of
UNINTERESTING in close_reachable(). This fixes the bug in manual
testing.

Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Szeder Gábor <szeder.dev@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25 11:19:16 +09:00
Derrick Stolee e88aab917e t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
config behavior. His example initially happened during a clone with
--recurse-submodules, we found that this happens with the first fetch
after cloning a repository that contains a submodule:

	$ git clone <url> test
	$ cd test
	$ git -c fetch.writeCommitGraph=true fetch origin
	Computing commit graph generation numbers: 100% (12/12), done.
	BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2>
	Aborted (core dumped)

In the repo I had cloned, there were really 60 commits to scan, but
only 12 were in the list to write when calling
compute_generation_numbers(). A commit in the list expects to see a
parent, but that parent is not in the list.

A follow-up will fix the bug, but first we create a test that
demonstrates the problem. This test must be careful about an existing
commit-graph file, since GIT_TEST_COMMIT_GRAPH=1 will cause the repo we
are cloning to already have one. This then prevents the incremtnal
commit-graph write during the first 'git fetch'.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Helped-by: Szeder Gábor <szeder.dev@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25 11:19:14 +09:00
Heba Waly 7b4fb434b4 documentation: remove empty doc files
Remove empty and redundant documentation files from the
Documentation/technical/ directory.

The empty doc files included only TODO messages with no documentation for
years. Instead an approach is being taken to keep all doc beside the code
in the relevant header files.
Having empty doc files is confusing and disappointing to anybody looking
for information, besides having the documentation in header files makes it
easier for developers to find the information they are looking for.

Some of the content which could have gone here already exists elsewhere:
- api-object-access.txt -> sha1-file.c and object.h have some details.
- api-quote.txt -> quote.h has some details.
- api-xdiff-interface.txt -> xdiff-interface.h has some details.
- api-grep.txt -> grep.h does not have enough documentation at the moment.

Signed-off-by: Heba Waly <heba.waly@gmail.com>
Reviewed-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25 11:18:14 +09:00
Junio C Hamano 566a1439f6 Git 2.24-rc1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 13:34:03 +09:00
Junio C Hamano 04b1f4f768 Merge branch 'sg/ci-osx-gcc8-fix'
CI build fix.

* sg/ci-osx-gcc8-fix:
  ci: fix GCC install in the Travis CI GCC OSX job
2019-10-24 13:34:03 +09:00
Junio C Hamano 4d6fb2beeb Merge branch 'ds/feature-macros'
The codepath that reads the index.version configuration was broken
with a recent update, which has been corrected.

* ds/feature-macros:
  repo-settings: read an int for index.version
2019-10-24 13:34:03 +09:00
Junio C Hamano 5f0b6ed907 Merge branch 'js/azure-ci-osx-fix'
Update installation procedure for Perforce on MacOS in the CI jobs
running on Azure pipelines, which was failing.

* js/azure-ci-osx-fix:
  ci(osx): use new location of the `perforce` cask
2019-10-24 13:34:02 +09:00
Junio C Hamano c555caab7a Merge branch 'bw/format-patch-o-create-leading-dirs'
Test update.

* bw/format-patch-o-create-leading-dirs:
  t4014: make output-directory tests self-contained
2019-10-24 13:34:02 +09:00
Junio C Hamano 1b4f85285f Merge branch 'dl/submodule-set-branch'
Test update.

* dl/submodule-set-branch:
  t7419: change test_must_fail to ! for grep
2019-10-24 13:34:02 +09:00
Jonathan Tan c7aadccba0 fetch: delay fetch_if_missing=0 until after config
Suppose, from a repository that has ".gitmodules", we clone with
--filter=blob:none:

  git clone --filter=blob:none --no-checkout \
    https://kernel.googlesource.com/pub/scm/git/git

Then we fetch:

  git -C git fetch

This will cause a "unable to load config blob object", because the
fetch_config_from_gitmodules() invocation in cmd_fetch() will attempt to
load ".gitmodules" (which Git knows to exist because the client has the
tree of HEAD) while fetch_if_missing is set to 0.

fetch_if_missing is set to 0 too early - ".gitmodules" here should be
lazily fetched.  Git must set fetch_if_missing to 0 before the fetch
because as part of the fetch, packfile negotiation happens (and we do
not want to fetch any missing objects when checking existence of
objects), but we do not need to set it so early. Move the setting of
fetch_if_missing to the earliest possible point in cmd_fetch(), right
before any fetching happens.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:34:44 +09:00
Derrick Stolee c11e9966cb repo-settings: read an int for index.version
Several config options were combined into a repo_settings struct in
ds/feature-macros, including a move of the "index.version" config
setting in 7211b9e (repo-settings: consolidate some config settings,
2019-08-13).

Unfortunately, that file looked like a lot of boilerplate and what is
clearly a factor of copy-paste overload, the config setting is parsed
with repo_config_ge_bool() instead of repo_config_get_int(). This means
that a setting "index.version=4" would not register correctly and would
revert to the default version of 3.

I caught this while incorporating v2.24.0-rc0 into the VFS for Git
codebase, where we really care that the index is in version 4.

This was not caught by the codebase because the version checks placed
in t1600-index.sh did not test the "basic" scenario enough. Here, we
modify the test to include these normal settings to not be overridden by
features.manyFiles or GIT_INDEX_VERSION. While the "default" version is
3, this is demoted to version 2 in do_write_index() when not necessary.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:33:45 +09:00
Denton Liu 091489d068 apply: respect merge.conflictStyle in --3way
Before, when doing a 3-way merge, the merge.conflictStyle option was not
respected and the "merge" style was always used, even if "diff3" was
specified.

Call git_xmerge_config() at the end of git_apply_config() so that the
merge.conflictStyle config is read.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:32:53 +09:00
Denton Liu aa76ae4905 t4108: demonstrate bug in apply
Currently, apply does not respect the merge.conflictStyle setting.
Demonstrate this by making the 'apply with --3way' test case generic and
extending it to show that the configuration of
merge.conflictStyle = diff3 causes a breakage.

Change print_sanitized_conflicted_diff() to also sanitize `|||||||`
conflict markers.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:32:53 +09:00
Denton Liu 95806205cd t4108: use test_config instead of git config
Since `git config` leaves the configurations set even after the test
case completes, use `test_config` instead so that the configurations are
reset once the test case finishes.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:32:53 +09:00
Denton Liu b0069684d4 t4108: remove git command upstream of pipe
Before, the output of `git diff HEAD` would always be piped to
sanitize_conflicted_diff(). However, since the Git command was upstream
of the pipe, in case the Git command fails, the return code would be
lost. Rewrite into separate statements so that the return code is no
longer lost.

Since only the command `git diff HEAD` was being piped to
sanitize_conflicted_diff(), move the command into the function and rename
it to print_sanitized_conflicted_diff().

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:32:53 +09:00
Denton Liu fa87b81385 t4108: replace create_file with test_write_lines
Since the locally defined create_file() duplicates the functionality of
the test_write_lines() helper function, remove create_file() and replace
all instances with test_write_lines(). While we're at it, move
redirection operators to the end of the command which is the more
conventional place to put it.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:32:53 +09:00
SZEDER Gábor 7d4733c501 ci: fix GCC install in the Travis CI GCC OSX job
A few days ago Travis CI updated their existing OSX images, including
the Homebrew database in the xcode10.1 OSX image that we use.  Since
then installing dependencies in the 'osx-gcc' job fails when it tries
to link gcc@8:

  + brew link gcc@8
  Error: No such keg: /usr/local/Cellar/gcc@8

GCC8 is still installed but not linked to '/usr/local' in the updated
image, as it was before this update, but now we have to link it by
running 'brew link gcc'.  So let's do that then, and fall back to
linking gcc@8 if it doesn't, just to be sure.

Our builds on Azure Pipelines are unaffected by this issue.  The OSX
image over there doesn't contain the gcc@8 package, so we have to
'brew install' it, which already takes care of linking it to
'/usr/local'.  After that the 'brew link gcc' command added by this
patch fails, but the ||-chained fallback 'brew link gcc@8' command
succeeds with an "already linked" warning.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:31:07 +09:00
Junio C Hamano d81542e6f3 Eleventh batch
The tenth was at -rc0 ;-)

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 14:43:11 +09:00
Junio C Hamano e0ff2d4c7e Merge branch 'cb/pcre2-chartables-leakfix'
Leakfix.

* cb/pcre2-chartables-leakfix:
  grep: avoid leak of chartables in PCRE2
  grep: make PCRE2 aware of custom allocator
  grep: make PCRE1 aware of custom allocator
2019-10-23 14:43:11 +09:00
Junio C Hamano d45d771978 Merge branch 'bc/smart-http-atomic-push'
The atomic push over smart HTTP transport did not work, which has
been corrected.

* bc/smart-http-atomic-push:
  remote-curl: pass on atomic capability to remote side
2019-10-23 14:43:11 +09:00
Junio C Hamano 22dd22dce0 Merge branch 'wb/fsmonitor-bitmap-fix'
A segfault fix.

* wb/fsmonitor-bitmap-fix:
  fsmonitor: don't fill bitmap with entries to be removed
2019-10-23 14:43:10 +09:00
Junio C Hamano 2e215b7959 Merge branch 'sb/userdiff-dts'
Tweak userdiff patterns for dts.

* sb/userdiff-dts:
  userdiff: fix some corner cases in dts regex
2019-10-23 14:43:10 +09:00
Junio C Hamano e3cf08361a Merge branch 'sg/progress-fix'
Byte-order fix the recent update to progress display code.

* sg/progress-fix:
  test-progress: fix test failures on big-endian systems
2019-10-23 14:43:09 +09:00
Junio C Hamano b895e8dea6 Merge branch 'nr/diff-highlight-indent-fix'
Code cleanup.

* nr/diff-highlight-indent-fix:
  diff-highlight: fix a whitespace nit
2019-10-23 14:43:09 +09:00
Junio C Hamano c1ec35dd48 Merge branch 'mb/clarify-zsh-completion-doc'
The installation instruction for zsh completion script (in
contrib/) has been a bit improved.

* mb/clarify-zsh-completion-doc:
  completion: clarify installation instruction for zsh
2019-10-23 14:43:09 +09:00
SZEDER Gábor f45f88b2e4 path.c: don't call the match function without value in trie_find()
'logs/refs' is not a working tree-specific path, but since commit
b9317d55a3 (Make sure refs/rewritten/ is per-worktree, 2019-03-07)
'git rev-parse --git-path' has been returning a bogus path if a
trailing '/' is present:

  $ git -C WT/ rev-parse --git-path logs/refs --git-path logs/refs/
  /home/szeder/src/git/.git/logs/refs
  /home/szeder/src/git/.git/worktrees/WT/logs/refs/

We use a trie data structure to efficiently decide whether a path
belongs to the common dir or is working tree-specific.  As it happens
b9317d55a3 triggered a bug that is as old as the trie implementation
itself, added in 4e09cf2acf (path: optimize common dir checking,
2015-08-31).

  - According to the comment describing trie_find(), it should only
    call the given match function 'fn' for a "/-or-\0-terminated
    prefix of the key for which the trie contains a value".  This is
    not true: there are three places where trie_find() calls the match
    function, but one of them is missing the check for value's
    existence.

  - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
    and 'logs/refs/worktree', next to the already existing
    'logs/refs/bisect'.  This resulted in a trie node with the path
    'logs/refs/', which didn't exist before, and which doesn't have a
    value attached.  A query for 'logs/refs/' finds this node and then
    hits that one callsite of the match function which doesn't check
    for the value's existence, and thus invokes the match function
    with NULL as value.

  - When the match function check_common() is invoked with a NULL
    value, it returns 0, which indicates that the queried path doesn't
    belong to the common directory, ultimately resulting the bogus
    path shown above.

Add the missing condition to trie_find() so it will never invoke the
match function with a non-existing value.  check_common() will then no
longer have to check that it got a non-NULL value, so remove that
condition.

I believe that there are no other paths that could cause similar bogus
output.  AFAICT the only other key resulting in the match function
being called with a NULL value is 'co' (because of the keys 'common'
and 'config').  However, as they are not in a directory that belongs
to the common directory the resulting working tree-specific path is
expected.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:54:22 +09:00
SZEDER Gábor c72fc40d09 path.c: clarify two field names in 'struct common_dir'
An array of 'struct common_dir' instances is used to specify whether
various paths in $GIT_DIR are specific to a worktree, or are common,
i.e. belong to main worktree.  The names of two fields in this
struct are somewhat confusing or ambigious:

  - The path is recorded in the struct's 'dirname' field, even though
    several entries are regular files e.g. 'gc.pid', 'packed-refs',
    etc.

    Rename this field to 'path' to reduce confusion.

  - The field 'exclude' tells whether the path is excluded...  from
    where?  Excluded from the common dir or from the worktree?  It
    means the former, but it's ambigious.

    Rename this field to 'is_common' to make it unambigious what it
    means.  This, however, means the exact opposite of what 'exclude'
    meant, so we have to negate the field's value in all entries as
    well.

The diff is best viewed with '--color-words'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor 8a64881b44 path.c: mark 'logs/HEAD' in 'common_list' as file
'logs/HEAD', i.e. HEAD's reflog, is a file, but its entry in
'common_list' has the 'is_dir' bit set.

Unset that bit to make it consistent with what 'logs/HEAD' is supposed
to be.

This doesn't make a difference in behavior: check_common() is the only
function that looks at the 'is_dir' bit, and that function either
returns 0, or '!exclude', which for 'logs/HEAD' results in 0 as well.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor 7cb8c929d7 path.c: clarify trie_find()'s in-code comment
A fairly long comment describes trie_find()'s behavior and shows
examples, but it's slightly incomplete/inaccurate.  Update this
comment to specify how trie_find() handles a negative return value
from the given match function.

Furthermore, update the list of examples to include not only two but
three levels of path components.  This makes the examples slightly
more complicated, but it can illustrate the behavior in more corner
cases.

Finally, basically everything refers to the data stored for a key as
"value", with two confusing exceptions:

  - The type definition of the match function calls its corresponding
    parameter 'data'.
    Rename that parameter to 'value'.  (check_common(), the only
    function of this type already calls it 'value').

  - The table of examples above trie_find() has a "val from node"
    column, which has nothing to do with the value stored in the trie:
    it's a "prefix of the key for which the trie contains a value"
    that led to that node.
    Rename that column header to "prefix to node".

Note that neither the original nor the updated description and
examples correspond 100% to the current implementation, because the
implementation is a bit buggy, but the comment describes the desired
behavior.  The bug will be fixed in the last patch of this series.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor e536b1fedf Documentation: mention more worktree-specific exceptions
If a directory in $GIT_DIR is overridden when $GIT_COMMON_DIR is set,
then usually all paths within that directory are overridden as well.
There are a couple of exceptions, though, and two of them, namely
'refs/rewritten' and 'logs/HEAD' are not mentioned in
'gitrepository-layout'.  Document them as well.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:50 +09:00
William Baker 680cba2c2b multi-pack-index: add [--[no-]progress] option.
Add the --[no-]progress option to git multi-pack-index.
Pass the MIDX_PROGRESS flag to the subcommand functions
when progress should be displayed by multi-pack-index.
The progress feature was added to 'verify' in 144d703
("multi-pack-index: report progress during 'verify'", 2018-09-13)
but some subcommands were not updated to display progress, and
the ability to opt-out was overlooked.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:06 +09:00