Junio C Hamano [Fri, 4 Oct 2019 04:13:05 +0000 (13:13 +0900)]
Merge branch 'bc/object-id-part17' into next
Preparation for SHA-256 upgrade continues.
* bc/object-id-part17: (26 commits)
midx: switch to using the_hash_algo
builtin/show-index: replace sha1_to_hex
rerere: replace sha1_to_hex
builtin/receive-pack: replace sha1_to_hex
builtin/index-pack: replace sha1_to_hex
packfile: replace sha1_to_hex
wt-status: convert struct wt_status to object_id
cache: remove null_sha1
builtin/worktree: switch null_sha1 to null_oid
builtin/repack: write object IDs of the proper length
pack-write: use hash_to_hex when writing checksums
sequencer: convert to use the_hash_algo
bisect: switch to using the_hash_algo
sha1-lookup: switch hard-coded constants to the_hash_algo
config: use the_hash_algo in abbrev comparison
combine-diff: replace GIT_SHA1_HEXSZ with the_hash_algo
bundle: switch to use the_hash_algo
connected: switch GIT_SHA1_HEXSZ to the_hash_algo
show-index: switch hard-coded constants to the_hash_algo
blame: remove needless comparison with GIT_SHA1_HEXSZ
...
Junio C Hamano [Thu, 3 Oct 2019 01:45:19 +0000 (10:45 +0900)]
Merge branch 'en/merge-recursive-cleanup' into next
The merge-recursive machiery is one of the most complex parts of
the system that accumulated cruft over time. This large series
cleans up the implementation quite a bit.
* en/merge-recursive-cleanup:
merge-recursive: fix the diff3 common ancestor label for virtual commits
Elijah Newren [Tue, 1 Oct 2019 18:17:27 +0000 (11:17 -0700)]
merge-recursive: fix the diff3 common ancestor label for virtual commits
In commit 743474cbfa8b ("merge-recursive: provide a better label for
diff3 common ancestor", 2019-08-17), the label for the common ancestor
was changed from always being
Unfortunately, this did not take into account that when we have a single
merge base, that merge base could be fake or constructed. In such
cases, this resulted in a label of "00000000". Of course, the previous
label of "merged common ancestors" was also misleading for this case.
Since we have an API that is explicitly about creating fake merge base
commits in merge_recursive_generic(), we should provide a better label
when using that API with one merge base. So, when
merge_recursive_generic() is called with one merge base, set the label
to:
"constructed merge base"
Note that callers of merge_recursive_generic() include the builtin
commands git-am (in combination with git apply --build-fake-ancestor),
git-merge-recursive, and git-stash.
Helped-by: Jeff King <peff@peff.net> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, when promisor_remote_move_to_tail() is called for a
promisor_remote which is currently the final element in promisors, a
cycle is created in the promisors linked list. This cycle leads to a
double free later on in promisor_remote_clear() when the final element
of the promisors list is removed: promisors is set to promisors->next (a
no-op, as promisors->next == promisors); the previous value of promisors
is free()'d; then the new value of promisors (which is equal to the
previous value of promisors) is also free()'d. This double-free error
was unrecoverable for the user without removing the filter or re-cloning
the repo and hoping to miss this edge case.
Now, when promisor_remote_move_to_tail() would be a no-op, just do a
no-op. In cases of promisor_remote_move_to_tail() where r is not already
at the tail of the list, it works as before.
Helped-by: Jeff King <peff@peff.net> Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Acked-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Tue, 1 Oct 2019 18:55:24 +0000 (11:55 -0700)]
dir: special case check for the possibility that pathspec is NULL
Commits 404ebceda01c ("dir: also check directories for matching
pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
match files under a dir, recurse into it", 2019-09-17) added calls to
match_pathspec() and do_match_pathspec() passing along their pathspec
parameter. Both match_pathspec() and do_match_pathspec() assume the
pathspec argument they are given is non-NULL. It turns out that
unpack-tree.c's verify_clean_subdirectory() calls read_directory() with
pathspec == NULL, and it is possible on case insensitive filesystems for
that NULL to make it to these new calls to match_pathspec() and
do_match_pathspec(). Add appropriate checks on the NULLness of pathspec
to avoid a segfault.
In case the negation throws anyone off (one of the calls was to
do_match_pathspec() while the other was to !match_pathspec(), yet no
negation of the NULLness of pathspec is used), there are two ways to
understand the differences:
* The code already handled the pathspec == NULL cases before this
series, and this series only tried to change behavior when there was
a pathspec, thus we only want to go into the if-block if pathspec is
non-NULL.
* One of the calls is for whether to recurse into a subdirectory, the
other is for after we've recursed into it for whether we want to
remove the subdirectory itself (i.e. the subdirectory didn't match
but something under it could have). That difference in situation
leads to the slight differences in logic used (well, that and the
slightly unusual fact that we don't want empty pathspecs to remove
untracked directories by default).
Denton found and analyzed one issue and provided the patch for the
match_pathspec() call, SZEDER figured out why the issue only reproduced
for some folks and not others and provided the testcase, and I looked
through the remainder of the series and noted the do_match_pathspec()
call that should have the same check.
Co-authored-by: Denton Liu <liu.denton@gmail.com> Co-authored-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 30 Sep 2019 04:42:14 +0000 (13:42 +0900)]
Merge branch 'jt/merge-recursive-symlink-is-not-a-dir-in-way' into next
A bug in merge-recursive code that triggers when a branch with a
symbolic link is merged with a branch that replaces it with a
directory has been fixed.
* jt/merge-recursive-symlink-is-not-a-dir-in-way:
merge-recursive: symlink's descendants not in way
Junio C Hamano [Mon, 30 Sep 2019 04:42:08 +0000 (13:42 +0900)]
Merge branch 'en/clean-nested-with-ignored' into next
"git clean" fixes.
* en/clean-nested-with-ignored:
clean: fix theoretical path corruption
clean: rewrap overly long line
clean: avoid removing untracked files in a nested git repository
clean: disambiguate the definition of -d
git-clean.txt: do not claim we will delete files with -n/--dry-run
dir: add commentary explaining match_pathspec_item's return value
dir: if our pathspec might match files under a dir, recurse into it
dir: make the DO_MATCH_SUBMODULE code reusable for a non-submodule case
dir: also check directories for matching pathspecs
dir: fix off-by-one error in match_pathspec_item
dir: fix typo in comment
t7300: add testcases showing failure to clean specified pathspecs
Junio C Hamano [Mon, 30 Sep 2019 04:42:06 +0000 (13:42 +0900)]
Merge branch 'dl/cocci-everywhere' into next
Coccinelle checks are done on more source files than before now.
* dl/cocci-everywhere:
Makefile: run coccicheck on more source files
Makefile: strip leading ./ in $(FIND_SOURCE_FILES)
Makefile: define THIRD_PARTY_SOURCES
Makefile: strip leading ./ in $(LIB_H)
Junio C Hamano [Mon, 30 Sep 2019 04:42:02 +0000 (13:42 +0900)]
Merge branch 'jk/disable-commit-graph-during-upload-pack' into next
The "upload-pack" (the counterpart of "git fetch") needs to disable
commit-graph when responding to a shallow clone/fetch request, but
the way this was done made Git panic, which has been corrected.
* jk/disable-commit-graph-during-upload-pack:
upload-pack: disable commit graph more gently for shallow traversal
commit-graph: bump DIE_ON_LOAD check to actual load-time
Junio C Hamano [Mon, 30 Sep 2019 04:42:00 +0000 (13:42 +0900)]
Merge branch 'rs/simplify-by-deco-with-deco-refs-exclude' into next
"git log --decorate-refs-exclude=<pattern>" was incorrectly
overruled when the "--simplify-by-decoration" option is used, which
has been corrected.
* rs/simplify-by-deco-with-deco-refs-exclude:
log-tree: call load_ref_decorations() in get_name_decoration()
log: test --decorate-refs-exclude with --simplify-by-decoration
Junio C Hamano [Mon, 30 Sep 2019 04:41:59 +0000 (13:41 +0900)]
Merge branch 'jk/partial-clone-sparse-blob' into next
The name of the blob object that stores the filter specification
for sparse cloning/fetching was interpreted in a wrong place in the
code, causing Git to abort.
* jk/partial-clone-sparse-blob:
list-objects-filter: use empty string instead of NULL for sparse "base"
list-objects-filter: give a more specific error sparse parsing error
list-objects-filter: delay parsing of sparse oid
t5616: test cloning/fetching with sparse:oid=<oid> filter
Junio C Hamano [Mon, 30 Sep 2019 04:41:58 +0000 (13:41 +0900)]
Merge branch 'ma/asciidoctor-refmiscinfo' into next
Update support for Asciidoctor documentation toolchain.
* ma/asciidoctor-refmiscinfo:
doc-diff: replace --cut-header-footer with --cut-footer
asciidoctor-extensions: provide `<refmiscinfo/>`
Doc/Makefile: give mansource/-version/-manual attributes
"git rebase --autostash <upstream> <branch>", when <branch> is
different from the current branch, incorrectly moved the tip of the
current branch, which has been corrected.
* bw/rebase-autostash-keep-current-branch:
builtin/rebase.c: Remove pointless message
builtin/rebase.c: make sure the active branch isn't moved when autostashing
Junio C Hamano [Mon, 30 Sep 2019 04:19:31 +0000 (13:19 +0900)]
Merge branch 'ds/include-exclude'
The internal code originally invented for ".gitignore" processing
got reshuffled and renamed to make it less tied to "excluding" and
stress more that it is about "matching", as it has been reused for
things like sparse checkout specification that want to check if a
path is "included".
* ds/include-exclude:
unpack-trees: rename 'is_excluded_from_list()'
treewide: rename 'exclude' methods to 'pattern'
treewide: rename 'EXCL_FLAG_' to 'PATTERN_FLAG_'
treewide: rename 'struct exclude_list' to 'struct pattern_list'
treewide: rename 'struct exclude' to 'struct path_pattern'
Junio C Hamano [Mon, 30 Sep 2019 04:19:31 +0000 (13:19 +0900)]
Merge branch 'jh/trace2-pretty-output'
Output from trace2 subsystem is formatted more prettily now.
* jh/trace2-pretty-output:
trace2: cleanup whitespace in perf format
trace2: cleanup whitespace in normal format
quote: add sq_append_quote_argv_pretty()
trace2: trim trailing whitespace in normal format error message
trace2: remove dead code in maybe_add_string_va()
trace2: trim whitespace in region messages in perf target format
trace2: cleanup column alignment in perf target format
Junio C Hamano [Mon, 30 Sep 2019 04:19:31 +0000 (13:19 +0900)]
Merge branch 'dl/rebase-i-keep-base'
"git rebase --keep-base <upstream>" tries to find the original base
of the topic being rebased and rebase on top of that same base,
which is useful when running the "git rebase -i" (and its limited
variant "git rebase -x").
The command also has learned to fast-forward in more cases where it
can instead of replaying to recreate identical commits.
* dl/rebase-i-keep-base:
rebase: teach rebase --keep-base
rebase tests: test linear branch topology
rebase: fast-forward --fork-point in more cases
rebase: fast-forward --onto in more cases
rebase: refactor can_fast_forward into goto tower
t3432: test for --no-ff's interaction with fast-forward
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests
t3432: test rebase fast-forward behavior
t3431: add rebase --fork-point tests
The command line completion support (in contrib/) learned about the
"--skip" option of "git revert" and "git cherry-pick".
* dl/complete-cherry-pick-revert-skip:
status: mention --skip for revert and cherry-pick
completion: add --skip for cherry-pick and revert
completion: merge options for cherry-pick and revert
Junio C Hamano [Mon, 30 Sep 2019 04:19:30 +0000 (13:19 +0900)]
Merge branch 'jk/misc-uninitialized-fixes'
Various fixes to codepaths gcc 9 had trouble following dataflow.
* jk/misc-uninitialized-fixes:
pack-objects: drop packlist index_pos optimization
test-read-cache: drop namelen variable
diff-delta: set size out-parameter to 0 for NULL delta
bulk-checkin: zero-initialize hashfile_checkpoint
pack-objects: use object_id in packlist_alloc()
git-am: handle missing "author" when parsing commit
Junio C Hamano [Mon, 30 Sep 2019 04:19:29 +0000 (13:19 +0900)]
Merge branch 'en/filter-branch-deprecation'
Start discouraging the use of "git filter-branch".
* en/filter-branch-deprecation:
t9902: use a non-deprecated command for testing
Recommend git-filter-repo instead of git-filter-branch
t6006: simplify, fix, and optimize empty message test
Junio C Hamano [Mon, 30 Sep 2019 04:19:23 +0000 (13:19 +0900)]
Merge branch 'dl/format-patch-doc-test-cleanup'
The documentation and tests for "git format-patch" have been
cleaned up.
* dl/format-patch-doc-test-cleanup:
config/format.txt: specify default value of format.coverLetter
Doc: add more detail for git-format-patch
t4014: stop losing return codes of git commands
t4014: remove confusing pipe in check_threading()
t4014: use test_line_count() where possible
t4014: let sed open its own files
t4014: drop redirections to /dev/null
t4014: use indentable here-docs
t4014: remove spaces after redirect operators
t4014: use sq for test case names
t4014: move closing sq onto its own line
t4014: s/expected/expect/
t4014: drop unnecessary blank lines from test cases
Martin Ågren [Sun, 22 Sep 2019 11:57:59 +0000 (13:57 +0200)]
user-manual.txt: render ASCII art correctly under Asciidoctor
This commit is similar to 379805051d ("Documentation: render revisions
correctly under Asciidoctor", 2018-05-06) and is a no-op with AsciiDoc.
When creating a literal block from an indented block without any sort of
delimiters, Asciidoctor strips off all leading whitespace, resulting in
a misrendered ASCII drawing. Use an explicit literal block to indicate
to Asciidoctor that we want to keep the leading whitespace. Drop the
common indentation for all lines to make this a no-op with AsciiDoc.
Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Martin Ågren [Sun, 22 Sep 2019 11:57:58 +0000 (13:57 +0200)]
asciidoctor-extensions.rb: handle "book" doctype in linkgit
user-manual.txt is the only file we process using the "book" doctype.
When we use AsciiDoc, user-manual.conf ensures that the linkgit macro
expands into something like
<ulink url="git-foo.html">git-foo(1)</ulink>
in user-manual.xml, which we then process into a clickable link, both in
user-manual.html and user-manual.pdf. With Asciidoctor,
user-manual.conf is ignored (this is expected) and our
Asciidoctor-specific implementation of linkgit kicks in:
This eventually renders as "git-foo(1)", which is not bad, but it
doesn't turn into a link.
Teach our Asciidoctor-specific implementation of the linkgit macro that
if the doctype is "book", we should emit <ulink .../> just like we do
with AsciiDoc. While we're doing this, future-proof by supporting a
"prefix". The implementation in user-manual.conf doesn't support this,
and we don't need this for now because user-manual.txt is the only file
we process this way (and it's immediately in Documentation/).
Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Martin Ågren [Sun, 22 Sep 2019 11:57:57 +0000 (13:57 +0200)]
user-manual.txt: change header notation
When AsciiDoc processes user-manual.txt, it generates a book containing
chapters containing sections. So for example, we have chapter 6,
"Advanced branch management", which contains four relatively short
sections, 6.1-6.4. Asciidoctor generates a book containing *parts*
containing *chapters* instead. So part 6, "Advanced branch management"
contains four short chapters, 1-4. This looks a bit odd.
To make AsciiDoc (8.6.10) and Asciidoctor (1.5.5) handle these the same,
change from indicating chapters like so:
[[foobar]]
Foobar
======
to doing it like so:
[[foobar]]
== Foobar
Same thing for sections (line of dashes to ===), subsections (line of
tildes to ====) and subsubsections (line of carets to =====). Mark the
appendices with "[appendix]", which both AsciiDoc and Asciidoctor
understand. This means we need to drop the "Appendix X: " from their
titles, or those "Appendix X: " would be included literally in the name
of the appendix.
This commit is a no-op for AsciiDoc: The generated user-manual.xml is
identical before and after this patch. Asciidoctor now creates the same
chapter-section-subsection structure as AsciiDoc.
Changing the book title at the start of the document to similarly use
"=" instead of a line of equal signs makes no difference with any of the
engines, but let's do that change anyway for consistency.
Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Martin Ågren [Sun, 22 Sep 2019 11:57:56 +0000 (13:57 +0200)]
user-manual.txt: add missing section label
We provide a label for each chapter and section except for the "Pitfalls
with submodules" section. Since we're doing it everywhere else, let's do
it here, too.
Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Denton Liu [Wed, 25 Sep 2019 08:21:01 +0000 (01:21 -0700)]
Makefile: emulate compile in $(HCO) target better
Currently, when testing headers using `make hdr-check`, headers are
directly compiled. Although this seems to test the headers, this is too
strict since we treat the headers as C sources. As a result, this will
cause warnings to appear that would otherwise not, such as a static
variable definition intended for later use throwing a unused variable
warning.
In addition, on platforms that can run `make hdr-check` but require
custom flags, this target was failing because none of them were being
passed to the compiler. For example, on MacOS, the NO_OPENSSL flag was
being set but it was not being passed into compiler so the check was
failing.
Fix these problems by emulating the compile process better, including
test compiling dummy *.hcc C sources generated from the *.h files and
passing $(ALL_CFLAGS) into the compiler for the $(HCO) target so that
these custom flags can be used.
Helped-by: Jeff King <peff@peff.net> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
and with `DEVELOPER=1`, we got the following warning on Arch Linux:
pack-bitmap.h:20:19: error: ‘BITMAP_IDX_SIGNATURE’ defined but not used [-Werror=unused-const-variable=]
20 | static const char BITMAP_IDX_SIGNATURE[] = {'B', 'I', 'T', 'M'};
| ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
"Use" the BITMAP_IDX_SIGNATURE variable by making the size of
bitmap_disk_header.magic equal to the size of BITMAP_IDX_SIGNATURE,
thereby eliminating the magic number (4).
An alternative was to simply add MAYBE_UNUSED, however that does not
eliminate the magic number.
Another alternative was to change the definition to
extern const char BITMAP_IDX_SIGNATURE[4];
However, this design was also not chosen as the static definition allows
us to keep the declaration together for readability along with removing
the magic number.
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Denton Liu [Wed, 25 Sep 2019 08:20:56 +0000 (01:20 -0700)]
promisor-remote.h: include missing header
When we ran `make hdr-check`, we got the following warning message:
promisor-remote.h:21:46: warning: declaration of 'struct repository' will not be visible outside of this function [-Wvisibility]
extern int promisor_remote_get_direct(struct repository *repo,
^
1 warning generated.
This was caused by a missing reference to `struct repository`, which is
defined in "repository.h".
Include this missing header to fix this warning.
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: trim leading and trailing whitespaces in author name
In some cases, the svn author names might contain leading or trailing
whitespaces, leading to messages such as:
Author: user1
not defined in authors.txt
(the trailing newline leads to the line break). The user "user1" is
defined in authors.txt though, e.g.
user1 = User <user1@example.com>
Fix this by trimming the author name retreived from svn before using it
in check_author.
Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Denton Liu [Sat, 21 Sep 2019 00:03:48 +0000 (17:03 -0700)]
promisor-remote.h: drop extern from function declaration
During the creation of this file, each time a new function declaration
was introduced, it included an `extern`. However, starting from 554544276a (*.[ch]: remove extern from function declarations using
spatch, 2019-04-29), we've been actively trying to prevent externs from
being used in function declarations because they're unnecessary.
Remove these spurious `extern`s.
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / git / log