summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2022-01-10Merge branch 'jl/subtree-check-parents-argument-passing-fix'Libravatar Junio C Hamano1-4/+3
Fix performance-releated bug in "git subtree" (in contrib/). * jl/subtree-check-parents-argument-passing-fix: subtree: fix argument handling in check_parents
2022-01-04subtree: fix argument handling in check_parentsLibravatar James Limbouris1-4/+3
315a84f9aa0 (subtree: use commits before rejoins for splits, 2018-09-28) changed the signature of check_parents from 'check_parents [REV...]' to 'check_parents PARENTS_EXPR INDENT'. In other words the variable list of parent revisions became a list embedded in a string. However it neglected to unpack the list again before sending it to cache_miss, leading to incorrect calls whenever more than one parent was present. This is the case whenever a merge commit is processed, with the end result being a loss of performance from unecessary rechecks. The indent parameter was subsequently removed in e9525a8a029 (subtree: have $indent actually affect indentation, 2021-04-27), but the argument handling bug remained. For consistency, take multiple arguments in check_parents, and pass all of them to cache_miss separately. Signed-off-by: James Limbouris <james@digitalmatter.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-03Merge branch 'es/test-chain-lint'Libravatar Junio C Hamano2-2/+2
Broken &&-chains in the test scripts have been corrected. * es/test-chain-lint: t6000-t9999: detect and signal failure within loop t5000-t5999: detect and signal failure within loop t4000-t4999: detect and signal failure within loop t0000-t3999: detect and signal failure within loop tests: simplify by dropping unnecessary `for` loops tests: apply modern idiom for exiting loop upon failure tests: apply modern idiom for signaling test failure tests: fix broken &&-chains in `{...}` groups tests: fix broken &&-chains in `$(...)` command substitutions tests: fix broken &&-chains in compound statements tests: use test_write_lines() to generate line-oriented output tests: simplify construction of large blocks of text t9107: use shell parameter expansion to avoid breaking &&-chain t6300: make `%(raw:size) --shell` test more robust t5516: drop unnecessary subshell and command invocation t4202: clarify intent by creating expected content less cleverly t1020: avoid aborting entire test script when one test fails t1010: fix unnoticed failure on Windows t/lib-pager: use sane_unset() to avoid breaking &&-chain
2021-12-21Merge branch 'js/scalar'Libravatar Junio C Hamano7-0/+1266
Add pieces from "scalar" to contrib/. * js/scalar: scalar: implement the `version` command scalar: implement the `delete` command scalar: teach 'reconfigure' to optionally handle all registered enlistments scalar: allow reconfiguring an existing enlistment scalar: implement the `run` command scalar: teach 'clone' to support the --single-branch option scalar: implement the `clone` subcommand scalar: implement 'scalar list' scalar: let 'unregister' handle a deleted enlistment directory gracefully scalar: 'unregister' stops background maintenance scalar: 'register' sets recommended config and starts maintenance scalar: create test infrastructure scalar: start documenting the command scalar: create a rudimentary executable scalar: add a README with a roadmap
2021-12-15Merge branch 'en/zdiff3'Libravatar Junio C Hamano1-3/+3
"Zealous diff3" style of merge conflict presentation has been added. * en/zdiff3: update documentation for new zdiff3 conflictStyle xdiff: implement a zealous diff3, or "zdiff3"
2021-12-15Merge branch 'hn/reftable'Libravatar Junio C Hamano2-3/+22
The "reftable" backend for the refs API, without integrating into the refs subsystem, has been added. * hn/reftable: Add "test-tool dump-reftable" command. reftable: add dump utility reftable: implement stack, a mutable database of reftable files. reftable: implement refname validation reftable: add merged table view reftable: add a heap-based priority queue for reftable records reftable: reftable file level tests reftable: read reftable files reftable: generic interface to tables reftable: write reftable files reftable: a generic binary tree implementation reftable: reading/writing blocks Provide zlib's uncompress2 from compat/zlib-compat.c reftable: (de)serialization for the polymorphic record type. reftable: add blocksource, an abstraction for random access reads reftable: utility functions reftable: add error related functionality reftable: add LICENSE hash.h: provide constants for the hash IDs
2021-12-13t6000-t9999: detect and signal failure within loopLibravatar Eric Sunshine1-1/+1
Failures within `for` and `while` loops can go unnoticed if not detected and signaled manually since the loop itself does not abort when a contained command fails, nor will a failure necessarily be detected when the loop finishes since the loop returns the exit code of the last command it ran on the final iteration, which may not be the command which failed. Therefore, detect and signal failures manually within loops using the idiom `|| return 1` (or `|| exit 1` within subshells). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13tests: fix broken &&-chains in `$(...)` command substitutionsLibravatar Eric Sunshine1-1/+1
The top-level &&-chain checker built into t/test-lib.sh causes tests to magically exit with code 117 if the &&-chain is broken. However, it has the shortcoming that the magic does not work within `{...}` groups, `(...)` subshells, `$(...)` substitutions, or within bodies of compound statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed` partly fills in the gap by catching broken &&-chains in `(...)` subshells, but bugs can still lurk behind broken &&-chains in the other cases. Fix broken &&-chains in `$(...)` command substitutions in order to reduce the number of possible lurking bugs. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-10Merge branch 'yn/complete-date-format-options'Libravatar Junio C Hamano1-1/+1
The completion script (in contrib/) learns that the "--date" option of commands from the "git log" family takes "human" and "auto" as valid values. * yn/complete-date-format-options: completion: add human and auto: date format
2021-12-10Merge branch 'bc/require-c99'Libravatar Junio C Hamano1-1/+1
Weather balloon to break people with compilers that do not support C99. * bc/require-c99: git-compat-util: add a test balloon for C99 support
2021-12-10Merge branch 'jk/jump-merge-with-pathspec'Libravatar Junio C Hamano2-1/+4
The "merge" subcommand of "git jump" (in contrib/) silently ignored pathspec and other parameters. * jk/jump-merge-with-pathspec: git-jump: pass "merge" arguments to ls-files
2021-12-04scalar: implement the `version` commandLibravatar Johannes Schindelin1-0/+39
The .NET version of Scalar has a `version` command. This was necessary because it was versioned independently of Git. Since Scalar is now tightly coupled with Git, it does not make sense for them to show different versions. Therefore, it shows the same output as `git version`. For backwards-compatibility with the .NET version, `scalar version` prints to `stderr`, though (`git version` prints to `stdout` instead). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: implement the `delete` commandLibravatar Matthew John Cheetham3-0/+80
Delete an enlistment by first unregistering the repository and then deleting the enlistment directory (usually the directory containing the worktree `src/` directory). On Windows, if the current directory is inside the enlistment's directory, change to the parent of the enlistment directory, to allow us to delete the enlistment (directories used by processes e.g. as current working directories cannot be deleted on Windows). Co-authored-by: Victoria Dye <vdye@github.com> Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: teach 'reconfigure' to optionally handle all registered enlistmentsLibravatar Johannes Schindelin3-6/+67
After a Scalar upgrade, it can come in really handy if there is an easy way to reconfigure all Scalar enlistments. This new option offers this functionality. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: allow reconfiguring an existing enlistmentLibravatar Johannes Schindelin3-28/+67
This comes in handy during Scalar upgrades, or when config settings were messed up by mistake. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: implement the `run` commandLibravatar Derrick Stolee2-0/+83
Note: this subcommand is provided primarily for backwards-compatibility, for existing Scalar uses. It is mostly just a shim for `git maintenance`, mapping task names from the way Scalar called them to the way Git calls them. The reason why those names differ? The background maintenance was first implemented in Scalar, and when it was contributed as a patch series implementing the `git maintenance` command, reviewers suggested better names, those suggestions were accepted before the patches were integrated into core Git. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: teach 'clone' to support the --single-branch optionLibravatar Johannes Schindelin3-4/+23
Just like `git clone`, the `scalar clone` command now also offers to restrict the clone to a single branch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: implement the `clone` subcommandLibravatar Johannes Schindelin3-3/+262
This implements Scalar's opinionated `clone` command: it tries to use a partial clone and sets up a sparse checkout by default. In contrast to `git clone`, `scalar clone` sets up the worktree in the `src/` subdirectory, to encourage a separation between the source files and the build output (which helps Git tremendously because it avoids untracked files that have to be specifically ignored when refreshing the index). Also, it registers the repository for regular, scheduled maintenance, and configures a flurry of configuration settings based on the experience and experiments of the Microsoft Windows and the Microsoft Office development teams. Note: since the `scalar clone` command is by far the most commonly called `scalar` subcommand, we document it at the top of the manual page. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: implement 'scalar list'Libravatar Derrick Stolee2-1/+21
The produced list simply consists of those repositories registered under the multi-valued `scalar.repo` config setting in the user's Git config. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: let 'unregister' handle a deleted enlistment directory gracefullyLibravatar Johannes Schindelin2-0/+61
When a user deleted an enlistment manually, let's be generous and _still_ unregister it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: 'unregister' stops background maintenanceLibravatar Derrick Stolee2-8/+50
Just like `scalar register` starts the scheduled background maintenance, `scalar unregister` stops it. Note that we use `git maintenance start` in `scalar register`, but we do not use `git maintenance stop` in `scalar unregister`: this would stop maintenance for _all_ repositories, not just for the one we want to unregister. The `unregister` command also removes the corresponding entry from the `[scalar]` section in the global Git config. Co-authored-by: Victoria Dye <vdye@github.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: 'register' sets recommended config and starts maintenanceLibravatar Derrick Stolee2-1/+266
Let's start implementing the `register` command. With this commit, recommended settings are configured upon `scalar register`, and Git's background maintenance is started. The recommended config settings may very well change in the future. For example, once the built-in FSMonitor is available, we will want to enable it upon `scalar register`. For that reason, we explicitly support running `scalar register` in an already-registered enlistment. Co-authored-by: Victoria Dye <vdye@github.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: create test infrastructureLibravatar Johannes Schindelin3-3/+109
To test the Scalar command, create a test script in contrib/scalar/t that is executed as `make -C contrib/scalar test`. Since Scalar has no meaningful capabilities yet, the only test is rather simple. We will add more tests in subsequent commits that introduce corresponding, new functionality. Note: This test script is intended to test `scalar` only lightly, even after all of the functionality is implemented. A more comprehensive functional (or: integration) test suite can be found at https://github.com/microsoft/scalar; It is used in the workflow https://github.com/microsoft/git/blob/HEAD/.github/workflows/scalar-functional-tests.yml in Microsoft's Git fork. This test suite performs end-to-end tests with a real remote repository, and is run as part of the regular CI and PR builds in that fork. Since those tests require some functionality supported only by Microsoft's Git fork ("GVFS protocol"), there is no intention to port that fuller test suite to `contrib/scalar/`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: start documenting the commandLibravatar Johannes Schindelin1-0/+38
Let's build up the documentation for the Scalar command along with the patches that implement its functionality. Note: To discourage the feature-incomplete documentation from being mistaken for the complete thing, we do not yet provide any way to build HTML or manual pages from the text file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: create a rudimentary executableLibravatar Johannes Schindelin3-0/+72
The idea of Scalar (https://github.com/microsoft/scalar), and before that, of VFS for Git, has always been to prove that Git _can_ scale, and to upstream whatever strategies have been demonstrated to help. With this patch, we start the journey from that C# project to move what is left to Git's own `contrib/` directory, reimplementing it in pure C, with the intention to facilitate integrating the functionality into core Git all while maintaining backwards-compatibility for existing Scalar users (which will be much easier when both live in the same worktree). It has always been the plan to contribute all of the proven strategies back to core Git. For example, while the virtual filesystem provided by VFS for Git helped the team developing the Windows operating system to move onto Git, while trying to upstream it we realized that it cannot be done: getting the virtual filesystem to work (which we only managed to implement fully on Windows, but not on, say, macOS or Linux), and the required server-side support for the GVFS protocol, made this not quite feasible. The Scalar project learned from that and tackled the problem with different tactics: instead of pretending to Git that the working directory is fully populated, it _specifically_ teaches Git about partial clone (which is based on VFS for Git's cache server), about sparse checkout (which VFS for Git tried to do transparently, in the file system layer), and regularly runs maintenance tasks to keep the repository in a healthy state. With partial clone, sparse checkout and `git maintenance` having been upstreamed, there is little left that `scalar.exe` does which `git.exe` cannot do. One such thing is that `scalar clone <url>` will automatically set up a partial, sparse clone, and configure known-helpful settings from the start. So let's bring this convenience into Git's tree. The idea here is that you can (optionally) build Scalar via make -C contrib/scalar/ This will build the `scalar` executable and put it into the contrib/scalar/ subdirectory. The slightly awkward addition of the `contrib/scalar/*` bits to the top-level `Makefile` are actually really required: we want to link to `libgit.a`, which means that we will need to use the very same `CFLAGS` and `LDFLAGS` as the rest of Git. An early development version of this patch tried to replicate all the conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like `contrib/svn-fe/Makefile` used to do before it was retired. It turned out to be quite the whack-a-mole game: the SHA-1-related flags, the flags enabling/disabling `compat/poll/`, `compat/regex/`, `compat/win32mmap.c` & friends depending on the current platform... To put it mildly: it was a major mess. Instead, this patch makes minimal changes to the top-level `Makefile` so that the bits in `contrib/scalar/` can be compiled and linked, and adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a most minimal way to do the actual compiling. Note: With this commit, we only establish the infrastructure, no Scalar functionality is implemented yet; We will do that incrementally over the next few commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-04scalar: add a README with a roadmapLibravatar Johannes Schindelin1-0/+82
The Scalar command will be contributed incrementally, over a bunch of patch series. Let's document what Scalar is about, and then describe the patch series that are planned. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01git-compat-util: add a test balloon for C99 supportLibravatar brian m. carlson1-1/+1
The C99 standard was released in January 1999, now 22 years ago. It provides a variety of useful features, including variadic arguments for macros, declarations after statements, designated initializers, and a wide variety of other useful features, many of which we already use. We'd like to take advantage of these features, but we want to be cautious. As far as we know, all major compilers now support C99 or a later C standard, such as C11 or C17. POSIX has required C99 support as a requirement for the 2001 revision, so we can safely assume any POSIX system which we are interested in supporting has C99. Even MSVC, long a holdout against modern C, now supports both C11 and C17 with an appropriate update. Moreover, even if people are using an older version of MSVC on these systems, they will generally need some implementation of the standard Unix utilities for the testsuite, and GNU coreutils, the most common option, has required C99 since 2009. Therefore, we can safely assume that a suitable version of GCC or clang is available to users even if their version of MSVC is not sufficiently capable. Let's add a test balloon to git-compat-util.h to see if anyone is using an older compiler. We'll add a comment telling people how to enable this functionality on GCC and Clang, even though modern versions of both will automatically do the right thing, and ask people still experiencing a problem to report that to us on the list. Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we use a well-known hack of using "- 0". On compilers with this macro, it doesn't change the value, and on C89 compilers, the macro will be replaced with nothing, and our value will be 0. For sparse, we explicitly request the gnu99 style because we've traditionally taken advantage of some GCC- and clang-specific extensions when available and we'd like to retain the ability to do that. sparse also defaults to C89 without it, so things will fail for us if we don't. Update the cmake configuration to require C11 for MSVC. We do this because this will make MSVC to use C11, since it does not explicitly support C99. We do this with a compiler options because setting the C_STANDARD option does not work in our CI on MSVC and at the moment, we don't want to require C11 for Unix compilers. In the Makefile, don't set any compiler flags for the compiler itself, since on some systems, such as FreeBSD, we actually need C11, and asking for C99 causes things to fail to compile. The error message should make it obvious what's going wrong and allow a user to set the appropriate option when building in the event they're using a Unix compiler that doesn't support it by default. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01xdiff: implement a zealous diff3, or "zdiff3"Libravatar Phillip Wood1-3/+3
"zdiff3" is identical to ordinary diff3 except that it allows compaction of common lines on the two sides of history at the beginning or end of the conflict hunk. For example, the following diff3 conflict: 1 2 3 4 <<<<<< A B C D E |||||| 5 6 ====== A X C Y E >>>>>> 7 8 9 has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one would instead get the following conflict: 1 2 3 4 A <<<<<< B C D |||||| 5 6 ====== X C Y >>>>>> E 7 8 9 Note that the common lines, 'A', and 'E' were moved outside the conflict. Unlike with the two-way conflicts from the 'merge' conflictStyle, the zdiff3 conflict is NOT split into multiple conflict regions to allow the common 'C' lines to be shown outside a conflict, because zdiff3 shows the base version too and the base version cannot be reasonably split. Note also that the removing of lines common to the two sides might make the remaining text inside the conflict region match the base text inside the conflict region (for example, if the diff3 conflict had '5 6 E' on the right side of the conflict, then the common line 'E' would be moved outside and both the base and right side's remaining conflict text would be the lines '5' and '6'). This has the potential to surprise users and make them think there should not have been a conflict, but there definitely was a conflict and it should remain. Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Co-authored-by: Elijah Newren <newren@gmail.com> Signed-off-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'ab/sh-retire-helper-functions'Libravatar Junio C Hamano1-1/+0
Make a few helper functions unused and then lose them. * ab/sh-retire-helper-functions: git-sh-setup: remove "sane_grep", it's not needed anymore git-sh-setup: remove unused sane_egrep() function git-instaweb: unconditionally assume that gitweb is mod_perl capable Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES) Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES) Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)
2021-11-29Merge branch 'tp/send-email-completion'Libravatar Junio C Hamano1-10/+1
The command line complation for "git send-email" options have been tweaked to make it easier to keep it in sync with the command itself. * tp/send-email-completion: send-email docs: add format-patch options send-email: programmatically generate bash completions
2021-11-25completion: add human and auto: date formatLibravatar Yoichi Nakayama1-1/+1
human was introduced in acdd37769de8b0fe37a74bfc0475b63bdc55e9dc auto:* was introduced in 2fd7c22992d37469db957e9a4d3884a6c0a4d182 Those formats were missing when other values were added to completion at 5a59a2301f6ec9bcf1b101edb9ca33beb465842f Signed-off-by: Yoichi Nakayama <yoichi.nakayama@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09git-jump: pass "merge" arguments to ls-filesLibravatar Jeff King2-1/+4
We currently throw away any arguments given to "git jump merge". We should instead pass them along to ls-files, since they're likely to be pathspecs. This matches the behavior of "git jump diff", etc. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-29Merge branch 're/completion-fix-test-equality'Libravatar Junio C Hamano1-1/+1
Fix long-standing shell syntax error in the completion script. * re/completion-fix-test-equality: completion: fix incorrect bash/zsh string equality check
2021-10-28completion: fix incorrect bash/zsh string equality checkLibravatar Robert Estelle1-1/+1
In the basic `[`/`test` command, the string equality operator is a single `=`. The `==` operator is only available in `[[`, which is a bash-ism also supported by zsh. This mix-up was causing the following completion error in zsh: > __git_ls_files_helper:7: = not found (That message refers to the extraneous symbol in `==` ← `=`). This updates that comparison to use a single `=` inside the basic `[ … ]` test conditional. Although this fix is inconsistent with the other comparisons in this file, which use `[[ … == … ]]`, and the two expressions are functionally identical in this context, that approach was rejected due to a preference for `[`. Signed-off-by: Robert Estelle <robertestelle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28send-email: programmatically generate bash completionsLibravatar Thiago Perrotta1-10/+1
"git send-email --git-completion-helper" only prints "format-patch" flags. Make it print "send-email" flags as well, extracting them programmatically from its three existing "GetOptions". Introduce a "uniq" subroutine, otherwise --cc-cover, --to-cover and other flags would show up twice. In addition, deduplicate flags common to both "send-email" and "format-patch", like --from. Remove extraneous flags: --h and --git-completion-helper. Add trailing "=" to options that expect an argument, inline with the format-patch implementation. Add a completion test for "send-email --validate", a send-email flag. Signed-off-by: Thiago Perrotta <tbperrotta@gmail.com> Based-on-patch-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21git-sh-setup: remove "sane_grep", it's not needed anymoreLibravatar Ævar Arnfjörð Bjarmason1-1/+0
Remove the sane_grep() shell function in git-sh-setup. The two reasons for why it existed don't apply anymore: 1. It was added due to GNU grep supporting GREP_OPTIONS. See e1622bfcbad (Protect scripted Porcelains from GREP_OPTIONS insanity, 2009-11-23). Newer versions of GNU grep ignore that, but even on older versions its existence won't matter, none of these sane_grep() uses care about grep's output, they're merely using it to check if a string exists in a file or stream. We also don't care about the "LC_ALL=C" that "sane_grep" was using, these greps for fixed or ASCII strings will behave the same under any locale. 2. The SANE_TEXT_GREP added in 71b401032b9 (sane_grep: pass "-a" if grep accepts it, 2016-03-08) isn't needed either, none of these grep uses deal with binary data. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano1-1/+1
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-13Merge branch 'ab/help-config-vars'Libravatar Junio C Hamano1-11/+10
Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation
2021-10-13Merge branch 'ab/config-based-hooks-1'Libravatar Junio C Hamano1-0/+7
Mostly preliminary clean-up in the hook API. * ab/config-based-hooks-1: hook-list.h: add a generated list of hooks, like config-list.h hook.c users: use "hook_exists()" instead of "find_hook()" hook.c: add a hook_exists() wrapper and use it in bugreport.c hook.[ch]: move find_hook() from run-command.c to hook.c Makefile: remove an out-of-date comment Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Makefile: stop hardcoding {command,config}-list.h Makefile: mark "check" target as .PHONY
2021-10-13Merge branch 'en/removing-untracked-fixes'Libravatar Junio C Hamano1-1/+1
Various fixes in code paths that move untracked files away to make room. * en/removing-untracked-fixes: Documentation: call out commands that nuke untracked files/directories Comment important codepaths regarding nuking untracked files/dirs unpack-trees: avoid nuking untracked dir in way of locally deleted file unpack-trees: avoid nuking untracked dir in way of unmerged file Change unpack_trees' 'reset' flag into an enum Remove ignored files by default when they are in the way unpack-trees: make dir an internal-only struct unpack-trees: introduce preserve_ignored to unpack_trees_options read-tree, merge-recursive: overwrite ignored files by default checkout, read-tree: fix leak of unpack_trees_options.dir t2500: add various tests for nuking untracked files
2021-10-12Merge branch 'rs/xopen-reports-open-failures' into maintLibravatar Junio C Hamano1-0/+16
Error diagnostics improvement. * rs/xopen-reports-open-failures: use xopen() to handle fatal open(2) failures xopen: explicitly report creation failures
2021-10-12Merge branch 'ti/tcsh-completion-regression-fix' into maintLibravatar Junio C Hamano1-2/+3
Update to the command line completion (in contrib/) for tcsh. * ti/tcsh-completion-regression-fix: completion: tcsh: Fix regression by drop of wrapper functions
2021-10-12Merge branch 'fc/completion-updates' into maintLibravatar Junio C Hamano1-7/+7
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-10-08reftable: utility functionsLibravatar Han-Wen Nienhuys2-3/+22
This commit provides basic utility classes for the reftable library. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27*.[ch] *_INIT macros: use { 0 } for a "zero out" idiomLibravatar Ævar Arnfjörð Bjarmason2-2/+2
In C it isn't required to specify that all members of a struct are zero'd out to 0, NULL or '\0', just providing a "{ 0 }" will accomplish that. Let's also change code that provided N zero'd fields to just provide one, and change e.g. "{ NULL }" to "{ 0 }" for consistency. I.e. even if the first member is a pointer let's use "0" instead of "NULL". The point of using "0" consistently is to pick one, and to not have the reader wonder why we're not using the same pattern everywhere. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27Comment important codepaths regarding nuking untracked files/dirsLibravatar Elijah Newren1-1/+1
In the last few commits we focused on code in unpack-trees.c that mistakenly removed untracked files or directories. There may be more of those, but in this commit we change our focus: callers of toplevel commands that are expected to remove untracked files or directories. As noted previously, we have toplevel commands that are expected to delete untracked files such as 'read-tree --reset', 'reset --hard', and 'checkout --force'. However, that does not mean that other highlevel commands that happen to call these other commands thought about or conveyed to users the possibility that untracked files could be removed. Audit the code for such callsites, and add comments near existing callsites to mention whether these are safe or not. My auditing is somewhat incomplete, though; it skipped several cases: * git-rebase--preserve-merges.sh: is in the process of being deprecated/removed, so I won't leave a note that there are likely more bugs in that script. * contrib/git-new-workdir: why is the -f flag being used in a new empty directory?? It shouldn't hurt, but it seems useless. * git-p4.py: Don't see why -f is needed for a new dir (maybe it's not and is just superfluous), but I'm not at all familiar with the p4 stuff * git-archimport.perl: Don't care; arch is long since dead * git-cvs*.perl: Don't care; cvs is long since dead Also, the reset --hard in builtin/worktree.c looks safe, due to only running in an empty directory. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27hook-list.h: add a generated list of hooks, like config-list.hLibravatar Ævar Arnfjörð Bjarmason1-0/+7
Make githooks(5) the source of truth for what hooks git supports, and punt out early on hooks we don't know about in find_hook(). This ensures that the documentation and the C code's idea about existing hooks doesn't diverge. We still have Perl and Python code running its own hooks, but that'll be addressed by Emily Shaffer's upcoming "git hook run" command. This resolves a long-standing TODO item in bugreport.c of there being no centralized listing of hooks, and fixes a bug with the bugreport listing only knowing about 1/4 of the p4 hooks. It didn't know about the recent "reference-transaction" hook either. We could make the find_hook() function die() or BUG() out if the new known_hook() returned 0, but let's make it return NULL just as it does when it can't find a hook of a known type. Making it die() is overly anal, and unlikely to be what we need in catching stupid typos in the name of some new hook hardcoded in git.git's sources. By making this be tolerant of unknown hook names, changes in a later series to make "git hook run" run arbitrary user-configured hook names will be easier to implement. I have not been able to directly test the CMake change being made here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for vs-build job, 2020-06-26) some of the Windows CI has a hard dependency on CMake, this change works there, and is to my eyes an obviously correct use of a pattern established in previous CMake changes, namely: - 061c2240b1 (Introduce CMake support for configuring Git, 2020-06-12) - 709df95b78 (help: move list_config_help to builtin/help, 2020-04-16) - 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual Studio solution, 2019-07-29) The LC_ALL=C is needed because at least in my locale the dash ("-") is ignored for the purposes of sorting, which results in a different order. I'm not aware of anything in git that has a hard dependency on the order, but e.g. the bugreport output would end up using whatever locale was in effect when git was compiled. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Merge branch 'rs/use-xopen-in-index-pack'Libravatar Junio C Hamano1-5/+8
Code clean-up. * rs/use-xopen-in-index-pack: index-pack: use xopen in init_thread
2021-09-23