summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-24githooks.txt: use correct "reference-transaction" hook nameLibravatar Bojun Chen1-2/+2
The "reference transaction" hook was introduced in commit 6754159767 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <bojun.cbj@alibaba-inc.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19refs: implement reference transaction hookLibravatar Patrick Steinhardt4-2/+244
The low-level reference transactions used to update references are currently completely opaque to the user. While certainly desirable in most usecases, there are some which might want to hook into the transaction to observe all queued reference updates as well as observing the abortion or commit of a prepared transaction. One such usecase would be to have a set of replicas of a given Git repository, where we perform Git operations on all of the repositories at once and expect the outcome to be the same in all of them. While there exist hooks already for a certain subset of Git commands that could be used to implement a voting mechanism for this, many others currently don't have any mechanism for this. The above scenario is the motivation for the new "reference-transaction" hook that reaches directly into Git's reference transaction mechanism. The hook receives as parameter the current state the transaction was moved to ("prepared", "committed" or "aborted") and gets via its standard input all queued reference updates. While the exit code gets ignored in the "committed" and "aborted" states, a non-zero exit code in the "prepared" state will cause the transaction to be aborted prematurely. Given the usecase described above, a voting mechanism can now be implemented via this hook: as soon as it gets called, it will take all of stdin and use it to cast a vote to a central service. When all replicas of the repository agree, the hook will exit with zero, otherwise it will abort the transaction by returning non-zero. The most important upside is that this will catch _all_ commands writing references at once, allowing to implement strong consistency for reference updates via a single mechanism. In order to test the impact on the case where we don't have any "reference-transaction" hook installed in the repository, this commit introduce two new performance tests for git-update-refs(1). Run against an empty repository, it produces the following results: Test origin/master HEAD -------------------------------------------------------------------- 1400.2: update-ref 2.70(2.10+0.71) 2.71(2.10+0.73) +0.4% 1400.3: update-ref --stdin 0.21(0.09+0.11) 0.21(0.07+0.14) +0.0% The performance test p1400.2 creates, updates and deletes a branch a thousand times, thus averaging runtime of git-update-refs over 3000 invocations. p1400.3 instead calls `git-update-refs --stdin` three times and queues a thousand creations, updates and deletes respectively. As expected, p1400.3 consistently shows no noticeable impact, as for each batch of updates there's a single call to access(3P) for the negative hook lookup. On the other hand, for p1400.2, one can see an impact caused by this patchset. But doing five runs of the performance tests where each one was run with GIT_PERF_REPEAT_COUNT=10, the overhead ranged from -1.5% to +1.1%. These inconsistent performance numbers can be explained by the overhead of spawning 3000 processes. This shows that the overhead of assembling the hook path and executing access(3P) once to check if it's there is mostly outweighed by the operating system's overhead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17The third batchLibravatar Junio C Hamano2-1/+25
Also let's update the DEF_VER in GIT-VERSION-GEN that presuably is not looked at by anybody ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17Merge branch 'es/advertise-contribution-doc'Libravatar Junio C Hamano2-2/+6
Doc updates. * es/advertise-contribution-doc: docs: mention MyFirstContribution in more places
2020-06-17Merge branch 'dl/python-2.7-is-the-floor-version'Libravatar Junio C Hamano1-6/+1
Document that we do not support Python 2.6 or older. * dl/python-2.7-is-the-floor-version: CodingGuidelines: specify Python 2.7 is the oldest version
2020-06-17Merge branch 'dl/t-readme-spell-git-correctly'Libravatar Junio C Hamano1-7/+7
Doc updates. * dl/t-readme-spell-git-correctly: t/README: avoid poor-man's small caps GIT
2020-06-17Merge branch 'js/fuzz-commit-graph-leakfix'Libravatar Junio C Hamano1-1/+1
Leakfix. * js/fuzz-commit-graph-leakfix: fuzz-commit-graph: properly free graph struct
2020-06-17Merge branch 'en/do-match-pathspec-fix'Libravatar Junio C Hamano2-17/+66
Use of negative pathspec, while collecting paths including untracked ones in the working tree, was broken. * en/do-match-pathspec-fix: dir: fix treatment of negated pathspecs
2020-06-17Merge branch 'js/msvc-build-fix'Libravatar Junio C Hamano1-1/+3
Workaround breakage in MSVC build, where "curl-config --cflags" gives settings appropriate for GCC build. * js/msvc-build-fix: msvc: fix "REG_STARTEND" issue
2020-06-17Merge branch 'en/sparse-checkout'Libravatar Junio C Hamano2-0/+26
The behaviour of "sparse-checkout" in the state "git clone --no-checkout" left was changed accidentally in 2.27, which has been corrected. * en/sparse-checkout: sparse-checkout: avoid staging deletions of all files
2020-06-17Merge branch 'js/reflog-anonymize-for-clone-and-fetch'Libravatar Junio C Hamano3-7/+30
The reflog entries for "git clone" and "git fetch" did not anonymize the URL they operated on. * js/reflog-anonymize-for-clone-and-fetch: clone/fetch: anonymize URLs in the reflog
2020-06-17Merge branch 'tb/t5318-cleanup'Libravatar Junio C Hamano1-4/+25
Code cleanup. * tb/t5318-cleanup: t5318: test that '--stdin-commits' respects '--[no-]progress' t5318: use 'test_must_be_empty'
2020-06-17Merge branch 'jk/diff-memuse-optim-with-stat-unmatch'Libravatar Junio C Hamano1-1/+4
Reduce memory usage during "diff --quiet" in a worktree with too many stat-unmatched paths. * jk/diff-memuse-optim-with-stat-unmatch: diff: discard blob data from stat-unmatched pairs
2020-06-12Merge branch 'hn/refs-cleanup'Libravatar Junio C Hamano9-25/+1137
Preliminary clean-ups around refs API, plus file format specification documentation for the reftable backend. * hn/refs-cleanup: reftable: define version 2 of the spec to accomodate SHA256 reftable: clarify how empty tables should be written reftable: file format documentation refs: improve documentation for ref iterator t: use update-ref and show-ref to reading/writing refs refs.h: clarify reflog iteration order
2020-06-09reftable: define version 2 of the spec to accomodate SHA256Libravatar Han-Wen Nienhuys1-37/+45
Version appends a hash ID to the file header, making it slightly larger. This commit also changes "SHA-1" into "object ID" in many places. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-09reftable: clarify how empty tables should be writtenLibravatar Han-Wen Nienhuys1-0/+6
The format allows for some ambiguity, as a lone footer also starts with a valid file header. However, the current JGit code will barf on this. This commit codifies this behavior into the standard. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-09reftable: file format documentationLibravatar Jonathan Nieder2-0/+1070
Shawn Pearce explains: Some repositories contain a lot of references (e.g. android at 866k, rails at 31k). The reftable format provides: - Near constant time lookup for any single reference, even when the repository is cold and not in process or kernel cache. - Near constant time verification if a SHA-1 is referred to by at least one reference (for allow-tip-sha1-in-want). - Efficient lookup of an entire namespace, such as `refs/tags/`. - Support atomic push `O(size_of_update)` operations. - Combine reflog storage with ref storage. This file format spec was originally written in July, 2017 by Shawn Pearce. Some refinements since then were made by Shawn and by Han-Wen Nienhuys based on experiences implementing and experimenting with the format. (All of this was in the context of our work at Google and Google is happy to contribute the result to the Git project.) Imported from JGit[1]'s current version (c217d33ff, "Documentation/technical/reftable: improve repo layout", 2020-02-04) of Documentation/technical/reftable.md and converted to asciidoc by running pandoc -t asciidoc -f markdown reftable.md >reftable.txt using pandoc 2.2.1. The result required the following additional minor changes: - removed the [TOC] directive to add a table of contents, since asciidoc does not support it - replaced git-scm.com/docs links with linkgit: directives that link to other pages within Git's documentation [1] https://eclipse.googlesource.com/jgit/jgit Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08The second batchLibravatar Junio C Hamano1-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08Merge branch 'jt/curl-verbose-on-trace-curl'Libravatar Junio C Hamano8-9/+74
Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL. Looking good. * jt/curl-verbose-on-trace-curl: http, imap-send: stop using CURLOPT_VERBOSE t5551: test that GIT_TRACE_CURL redacts password
2020-06-08Merge branch 'cc/upload-pack-data'Libravatar Junio C Hamano1-153/+145
Code clean-up. * cc/upload-pack-data: upload-pack: use upload_pack_data fields in receive_needs() upload-pack: pass upload_pack_data to create_pack_file() upload-pack: remove static variable 'stateless_rpc' upload-pack: pass upload_pack_data to check_non_tip() upload-pack: pass upload_pack_data to send_ref() upload-pack: move symref to upload_pack_data upload-pack: use upload_pack_data writer in receive_needs() upload-pack: pass upload_pack_data to receive_needs() upload-pack: pass upload_pack_data to get_common_commits() upload-pack: use 'struct upload_pack_data' in upload_pack() upload-pack: move 'struct upload_pack_data' around upload-pack: move {want,have}_obj to upload_pack_data upload-pack: remove unused 'wants' from upload_pack_data
2020-06-08Merge branch 'cb/bisect-helper-parser-fix'Libravatar Junio C Hamano2-4/+11
The code to parse "git bisect start" command line was lax in validating the arguments. * cb/bisect-helper-parser-fix: bisect--helper: avoid segfault with bad syntax in `start --term-*`
2020-06-08Merge branch 'js/checkout-p-new-file'Libravatar Junio C Hamano3-9/+61
"git checkout -p" did not handle a newly added path at all. * js/checkout-p-new-file: checkout -p: handle new files correctly
2020-06-08Merge branch 'dl/remote-curl-deadlock-fix'Libravatar Junio C Hamano18-30/+211
On-the-wire protocol v2 easily falls into a deadlock between the remote-curl helper and the fetch-pack process when the server side prematurely throws an error and disconnects. The communication has been updated to make it more robust. * dl/remote-curl-deadlock-fix: stateless-connect: send response end packet pkt-line: define PACKET_READ_RESPONSE_END remote-curl: error on incomplete packet pkt-line: extern packet_length() transport: extract common fetch_pack() call remote-curl: remove label indentation remote-curl: fix typo
2020-06-08Merge branch 'bc/filter-process'Libravatar Junio C Hamano2-3/+9
Code simplification and test coverage enhancement. * bc/filter-process: t2060: add a test for switch with --orphan and --discard-changes builtin/checkout: simplify metadata initialization
2020-06-08Merge branch 'vs/complete-stash-show-p-fix'Libravatar Junio C Hamano1-1/+1
The command line completion script (in contrib/) tried to complete "git stash -p" as if it were "git stash push -p", but it was too aggressive and also affected "git stash show -p", which has been corrected. * vs/complete-stash-show-p-fix: completion: don't override given stash subcommand with -p
2020-06-08Merge branch 'rs/fsck-duplicate-names-in-trees'Libravatar Junio C Hamano2-17/+30
The check in "git fsck" to ensure that the tree objects are sorted still had corner cases it missed unsorted entries. * rs/fsck-duplicate-names-in-trees: fsck: detect more in-tree d/f conflicts t1450: demonstrate undetected in-tree d/f conflict t1450: increase test coverage of in-tree d/f detection fsck: fix a typo in a comment
2020-06-08Merge branch 'es/bugreport-shell'Libravatar Junio C Hamano3-0/+8
"git bugreport" learns to report what shell is in use. * es/bugreport-shell: bugreport: include user interactive shell help: add shell-path to --build-options
2020-06-08Merge branch 'tb/commit-graph-no-check-oids'Libravatar Junio C Hamano5-77/+95
Clean-up the commit-graph codepath. * tb/commit-graph-no-check-oids: commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag t5318: reorder test below 'graph_read_expect' commit-graph.c: simplify 'fill_oids_from_commits' builtin/commit-graph.c: dereference tags in builtin builtin/commit-graph.c: extract 'read_one_commit()' commit-graph.c: peel refs in 'add_ref_to_set' commit-graph.c: show progress of finding reachable commits commit-graph.c: extract 'refs_cb_data'
2020-06-08Merge branch 'cb/t4210-illseq-auto-detect'Libravatar Junio C Hamano3-52/+125
As FreeBSD is not the only platform whose regexp library reports a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that automatically and skip the affected tests. * cb/t4210-illseq-auto-detect: t4210: detect REG_ILLSEQ dynamically and skip affected tests t/helper: teach test-regex to report pattern errors (like REG_ILLSEQ)
2020-06-08Merge branch 'ds/line-log-on-bloom'Libravatar Junio C Hamano6-13/+152
"git log -L..." now takes advantage of the "which paths are touched by this commit?" info stored in the commit-graph system. * ds/line-log-on-bloom: line-log: integrate with changed-path Bloom filters line-log: try to use generation number-based topo-ordering line-log: more responsive, incremental 'git log -L' t4211-line-log: add tests for parent oids line-log: remove unused fields from 'struct line_log_data'
2020-06-08docs: mention MyFirstContribution in more placesLibravatar Emily Shaffer2-2/+6
While the MyFirstContribution guide exists and has received some use and positive reviews, it is still not as discoverable as it could be. Add a reference to it from the GitHub pull request template, where many brand-new contributors may look. Also add a reference to it in SubmittingPatches, which is the central source of guidance for patch contribution. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Reviewed-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08CodingGuidelines: specify Python 2.7 is the oldest versionLibravatar Denton Liu1-6/+1
In 0b4396f068 (git-p4: make python2.7 the oldest supported version, 2019-12-13), git-p4 was updated to only support 2.7 and newer. Since Python 2.6 is pretty much ancient history, update CodingGuidelines to show that 2.7 is the oldest version supported. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08t/README: avoid poor-man's small caps GITLibravatar Denton Liu1-7/+7
In 48a8c26c62 (Documentation: avoid poor-man's small caps GIT, 2013-01-21), the documentation was amended to spell Git's name as Git when talking about the system as a whole. However, t/README was skipped over when the treatment was applied. Bring t/README into conformance with the CodingGuidelines by casing "Git" properly. While we're at it, fix a small typo. Change "the git internal" to "the Git internals". Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08fuzz-commit-graph: properly free graph structLibravatar Josh Steadmon1-1/+1
Use the provided free_commit_graph() to properly free the commit graph in fuzz-commit-graph. Otherwise, the fuzzer itself leaks memory when the struct contains pointers to allocated memory. Signed-off-by: Josh Steadmon <steadmon@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-05dir: fix treatment of negated pathspecsLibravatar Elijah Newren2-17/+66
do_match_pathspec() started life as match_pathspec_depth_1() and for correctness was only supposed to be called from match_pathspec_depth(). match_pathspec_depth() was later renamed to match_pathspec(), so the invariant we expect today is that do_match_pathspec() has no direct callers outside of match_pathspec(). Unfortunately, this intention was lost with the renames of the two functions, and additional calls to do_match_pathspec() were added in commits 75a6315f74 ("ls-files: add pathspec matching for submodules", 2016-10-07) and 89a1f4aaf7 ("dir: if our pathspec might match files under a dir, recurse into it", 2019-09-17). Of course, do_match_pathspec() had an important advantge over match_pathspec() -- match_pathspec() would hardcode flags to one of two values, and these new callers needed to pass some other value for flags. Also, although calling do_match_pathspec() directly was incorrect, there likely wasn't any difference in the observable end output, because the bug just meant that fill_diretory() would recurse into unneeded directories. Since subsequent does-this-path-match checks on individual paths under the directory would cause those extra paths to be filtered out, the only difference from using the wrong function was unnecessary computation. The second of those bad calls to do_match_pathspec() was involved -- via either direct movement or via copying+editing -- into a number of later refactors. See commits 777b420347 ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), 8d92fb2927 ("dir: replace exponential algorithm with a linear one", 2020-04-01), and 95c11ecc73 ("Fix error-prone fill_directory() API; make it only return matches", 2020-04-01). The last of those introduced the usage of do_match_pathspec() on an individual file, and thus resulted in individual paths being returned that shouldn't be. The problem with calling do_match_pathspec() instead of match_pathspec() is that any negated patterns such as ':!unwanted_path` will be ignored. Add a new match_pathspec_with_flags() function to fulfill the needs of specifying special flags while still correctly checking negated patterns, add a big comment above do_match_pathspec() to prevent others from misusing it, and correct current callers of do_match_pathspec() to instead use either match_pathspec() or match_pathspec_with_flags(). One final note is that DO_MATCH_LEADING_PATHSPEC needs special consideration when working with DO_MATCH_EXCLUDE. The point of DO_MATCH_LEADING_PATHSPEC is that if we have a pathspec like */Makefile and we are checking a directory path like src/module/component that we want to consider it a match so that we recurse into the directory because it _might_ have a file named Makefile somewhere below. However, when we are using an exclusion pattern, i.e. we have a pathspec like :(exclude)*/Makefile we do NOT want to say that a directory path like src/module/component is a (negative) match. While there *might* be a file named 'Makefile' somewhere below that directory, there could also be other files and we cannot pre-emptively rule all the files under that directory out; we need to recurse and then check individual files. Adjust the DO_MATCH_LEADING_PATHSPEC logic to only get activated for positive pathspecs. Reported-by: John Millikin <jmillikin@stripe.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-05sparse-checkout: avoid staging deletions of all filesLibravatar Elijah Newren2-0/+26
sparse-checkout's purpose is to update the working tree to have it reflect a subset of the tracked files. As such, it shouldn't be switching branches, making commits, downloading or uploading data, or staging or unstaging changes. Other than updating the worktree, the only thing sparse-checkout should touch is the SKIP_WORKTREE bit of the index. In particular, this sets up a nice invariant: running sparse-checkout will never change the status of any file in `git status` (reflecting the fact that we only set the SKIP_WORKTREE bit if the file is safe to delete, i.e. if the file is unmodified). Traditionally, we did a _really_ bad job with this goal. The predecessor to sparse-checkout involved manual editing of .git/info/sparse-checkout and running `git read-tree -mu HEAD`. That command would stage and unstage changes and overwrite dirty changes in the working tree. The initial implementation of the sparse-checkout command was no better; it simply invoked `git read-tree -mu HEAD` as a subprocess and had the same caveats, though this issue came up repeatedly in review comments and workarounds for the problems were put in place before the feature was merged[1, 2, 3, 4, 5, 6; especially see 4 & 6]. [1] https://lore.kernel.org/git/CABPp-BFT9A5n=_bx5LsjCvbogqwSjiwgr5amcjgbU1iAk4KLJg@mail.gmail.com/ [2] https://lore.kernel.org/git/CABPp-BEmwSwg4tgJg6nVG8a3Hpn_g-=ZjApZF4EiJO+qVgu4uw@mail.gmail.com/ [3] https://lore.kernel.org/git/CABPp-BFV7TA0qwZCQpHCqx9N+JifyRyuBQ-pZ_oGfe-NOgyh7A@mail.gmail.com/ [4] https://lore.kernel.org/git/CABPp-BHYCCD+Vx5fq35jH82eHc1-P53Lz_aGNpHJNcx9kg2K-A@mail.gmail.com/ [5] https://lore.kernel.org/git/CABPp-BF+JWYZfDqp2Tn4AEKVp4b0YMA=Mbz4Nz62D-gGgiduYQ@mail.gmail.com/ [6] https://lore.kernel.org/git/20191121163706.GV23183@szeder.dev/ However, these workarounds, in addition to disabling the feature in a number of important cases, also missed one special case. I'll get back to it later. In the 2.27.0 cycle, the disabling of the feature was lifted by finally replacing the internal equivalent of `git read-tree -mu HEAD` with something that did what we wanted: the new update_sparsity() function in unpack-trees.c that only ever updates SKIP_WORKTREE bits in the index and updates the working tree to match. This new function handles all the cases that were problematic for the old implementation, except that it breaks the same special case that avoided the workarounds of the old implementation, but broke it in a different way. So...that brings us to the special case: a git clone performed with --no-checkout. As per the meaning of the flag, --no-checkout does not check out any branch, with the implication that you aren't on one and need to switch to one after the clone. Implementationally, HEAD is still set (so in some sense you are partially on a branch), but * the index is "unborn" (non-existent) * there are no files in the working tree (other than .git/) * the next time git switch (or git checkout) is run it will run unpack_trees with `initial_checkout` flag set to true. It is not until you run, e.g. `git switch <somebranch>` that the index will be written and files in the working tree populated. With this special --no-checkout case, the traditional `read-tree -mu HEAD` behavior would have done the equivalent of acting like checkout -- switch to the default branch (HEAD), write out an index that matches HEAD, and update the working tree to match. This special case slipped through the avoid-making-changes checks in the original sparse-checkout command and thus continued there. After update_sparsity() was introduced and used (see commit f56f31af03 ("sparse-checkout: use new update_sparsity() function", 2020-03-27)), the behavior for the --no-checkout case changed: Due to git's auto-vivification of an empty in-memory index (see do_read_index() and note that `must_exist` is false), and due to sparse-checkout's update_working_directory() code to always write out the index after it was done, we got a new bug. That made it so that sparse-checkout would switch the repository from a clone with an "unborn" index (i.e. still needing an initial_checkout), to one that had a recorded index with no entries. Thus, instead of all the files appearing deleted in `git status` being known to git as a special artifact of not yet being on a branch, our recording of an empty index made it suddenly look to git as though it was definitely on a branch with ALL files staged for deletion! A subsequent checkout or switch then had to contend with the fact that it wasn't on an initial_checkout but had a bunch of staged deletions. Make sure that sparse-checkout changes nothing in the index other than the SKIP_WORKTREE bit; in particular, when the index is unborn we do not have any branch checked out so there is no sparsification or de-sparsification work to do. Simply return from update_working_directory() early. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04msvc: fix "REG_STARTEND" issueLibravatar Johannes Schindelin1-1/+3
In 897d68e7af82 (Makefile: use curl-config --cflags, 2020-03-26), we taught the build process to use `curl-config --cflags` to make sure that it can find cURL's headers. In the MSVC build, this is completely bogus because we're running in a Git for Windows SDK whose `curl-config` supports the _GCC_ build. Let's just ignore each and every `-I<path>` option where `<path>` points to GCC/Clang specific headers. Reported by Jeff Hostetler in https://github.com/microsoft/git/issues/275. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04clone/fetch: anonymize URLs in the reflogLibravatar Johannes Schindelin3-7/+30
Even if we strongly discourage putting credentials into the URLs passed via the command-line, there _is_ support for that, and users _do_ do that. Let's scrub them before writing them to the reflog. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04t5318: test that '--stdin-commits' respects '--[no-]progress'Libravatar Taylor Blau1-0/+21
The following lines were not covered in a recent line-coverage test against Git: builtin/commit-graph.c 5b6653e5 244) progress = start_delayed_progress( 5b6653e5 268) stop_progress(&progress); These statements are executed when both '--stdin-commits' and '--progress' are passed. Introduce a trio of tests that exercise various combinations of these options to ensure that these lines are covered. More importantly, this is exercising a (somewhat) previously-ignored feature of '--stdin-commits', which is that it respects '--progress'. Prior to 5b6653e523 (builtin/commit-graph.c: dereference tags in builtin, 2020-05-13), dereferencing input from '--stdin-commits' was done inside of commit-graph.c. Now that an additional progress meter may be generated from outside of commit-graph.c, add a corresponding test to make sure that it also respects '--[no]-progress'. The other location that generates progress meter output (from d335ce8f24 (commit-graph.c: show progress of finding reachable commits, 2020-05-13)) is already covered by any test that passes '--reachable'. Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04t5318: use 'test_must_be_empty'Libravatar Taylor Blau1-4/+4
A handful of tests in t5318 use 'test_line_count = 0 ...' to make sure that some command does not write any output. While correct, it is more idiomatic to use 'test_must_be_empty' instead. Switch the former invocations to use the latter instead. Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-02Start the post 2.27 cycleLibravatar Junio C Hamano2-1/+53
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-02Merge branch 'en/fast-import-looser-date'Libravatar Junio C Hamano3-5/+57
Some repositories in the wild have commits that record nonsense committer timezone (e.g. rails.git); "git fast-import" learned an option to pass these nonsense timestamps intact to allow recreating existing repositories as-is. * en/fast-import-looser-date: fast-import: add new --date-format=raw-permissive format
2020-06-02Merge branch 'mt/zsh-completion-optim'Libravatar Junio C Hamano1-1/+1
Command line completion (incontrib/) update. * mt/zsh-completion-optim: completion: use native ZSH array pattern matching
2020-06-02Merge branch 'la/diff-relative-config'Libravatar Junio C Hamano5-7/+108
The commands in the "diff" family learned to honor "diff.relative" configuration variable. * la/diff-relative-config: diff: add config option relative
2020-06-02Merge branch 'rs/checkout-b-track-error'Libravatar Junio C Hamano3-1/+35
The error message from "git checkout -b foo -t bar baz" was confusing. * rs/checkout-b-track-error: checkout: improve error messages for -b with extra argument checkout: add tests for -b and --track
2020-06-02Merge branch 'lo/sparse-universal-zero-init'Libravatar Junio C Hamano1-1/+1
We've adopted a convention that any on-stack structure can be initialized to have zero values in all fields with "= { 0 }", even when the first field happens to be a pointer, but sparse complained that a null pointer should be spelled NULL for a long time. Start using -Wno-universal-initializer option to squelch it. * lo/sparse-universal-zero-init: sparse: allow '{ 0 }' to be used without warnings
2020-06-02Merge branch 'cb/t5608-cleanup'Libravatar Junio C Hamano1-6/+5
Test fixup. * cb/t5608-cleanup: t5608: avoid say() and use "skip_all" instead for consistency
2020-06-02Merge branch 'jx/pkt-line-doc-count-fix'Libravatar Junio C Hamano2-4/+4
Docfix. * jx/pkt-line-doc-count-fix: doc: fix wrong 4-byte length of pkt-line message
2020-06-02Merge branch 'jn/experimental-opts-into-proto-v2'Libravatar Junio C Hamano3-1/+10
"feature.experimental" configuration variable is to let volunteers easily opt into a set of newer features, which use of the v2 transport protocol is now a part of. * jn/experimental-opts-into-proto-v2: config: let feature.experimental imply protocol.version=2
2020-06-02Merge branch 'bk/p4-prepare-p4-only-fix'Libravatar Junio C Hamano1-4/+5
The "--prepare-p4-only" option is supposed to stop after replaying one changeset, but kept going (by mistake?) * bk/p4-prepare-p4-only-fix: git-p4.py: fix --prepare-p4-only error with multiple commits