summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2022-03-13Merge branch 'ab/make-optim-noop'Libravatar Junio C Hamano2-15/+8
Makefile refactoring with a bit of suffixes rule stripping to optimize the runtime overhead. * ab/make-optim-noop: Makefiles: add and use wildcard "mkdir -p" template Makefile: add "$(QUIET)" boilerplate to shared.mak Makefile: move $(comma), $(empty) and $(space) to shared.mak Makefile: move ".SUFFIXES" rule to shared.mak Makefile: define $(LIB_H) in terms of $(FIND_SOURCE_FILES) Makefile: disable GNU make built-in wildcard rules Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it scalar Makefile: use "The default target of..." pattern
2022-03-06Merge branch 'jc/rerere-train-modernise'Libravatar Junio C Hamano1-1/+1
Small modernization of the rerere-train script (in contrib/). * jc/rerere-train-modernise: rerere-train: two fixes to the use of "git show -s"
2022-03-03Makefile: add "$(QUIET)" boilerplate to shared.makLibravatar Ævar Arnfjörð Bjarmason1-14/+0
The $(QUIET) variables we define are largely duplicated between our various Makefiles, let's define them in the new "shared.mak" instead. Since we're not using the environment to pass these around we don't need to export the "QUIET_GEN" and "QUIET_BUILT_IN" variables anymore. The "QUIET_GEN" variable is used in "git-gui/Makefile" and "gitweb/Makefile", but they've got their own definition for those. The "QUIET_BUILT_IN" variable is only used in the top-level "Makefile". We still need to export the "V" variable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to itLibravatar Ævar Arnfjörð Bjarmason2-0/+6
We have various behavior that's shared across our Makefiles, or that really should be (e.g. via defined templates). Let's create a top-level "shared.mak" to house those sorts of things, and start by adding the ".DELETE_ON_ERROR" flag to it. See my own 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) and db10fc6c09f (doc: simplify Makefile using .DELETE_ON_ERROR, 2021-05-21) for the addition and use of the ".DELETE_ON_ERROR" flag. I.e. this changes the behavior of existing rules in the altered Makefiles (except "Makefile" & "Documentation/Makefile"). I'm confident that this is safe having read the relevant rules in those Makfiles, and as the GNU make manual notes that it isn't the default behavior is out of an abundance of backwards compatibility caution. From edition 0.75 of its manual, covering GNU make 4.3: [Enabling '.DELETE_ON_ERROR' is] almost always what you want 'make' to do, but it is not historical practice; so for compatibility, you must explicitly request it. This doesn't introduce a bug by e.g. having this ".DELETE_ON_ERROR" flag only apply to this new shared.mak, Makefiles have no such scoping semantics. It does increase the danger that any Makefile without an explicit "The default target of this Makefile is..." snippet to define the default target as "all" could have its default rule changed if our new shared.mak ever defines a "real" rule. In subsequent commits we'll be careful not to do that, and such breakage would be obvious e.g. in the case of "make -C t". We might want to make that less fragile still (e.g. by using ".DEFAULT_GOAL" as noted in the preceding commit), but for now let's simply include "shared.mak" without adding that boilerplate to all the Makefiles that don't have it already. Most of those are already exposed to that potential caveat e.g. due to including "config.mak*". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03scalar Makefile: use "The default target of..." patternLibravatar Ævar Arnfjörð Bjarmason1-6/+7
Make the "contrib/scalar/Makefile" be stylistically consistent with the top-level "Makefile" in first declaring "all" to be the default rule, followed by including other Makefile snippets. This adjusts code added in 0a43fb22026 (scalar: create a rudimentary executable, 2021-12-03), it further ensures that when we add another "include" file in a subsequent commit that the included file won't be the one to define our default target. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-27rerere-train: two fixes to the use of "git show -s"Libravatar Junio C Hamano1-1/+1
The script uses "git show -s" to display the title of the merge commit being studied, without explicitly disabling the pager, which is not a safe thing to do in a script. For example, when the pager is set to "less" with "-SF" options (-S tells the pager not to fold lines but allow horizontal scrolling to show the overly long lines, -F tells the pager not to wait if the output in its entirety is shown on a single page), and the title of the merge commit is longer than the width of the terminal, the pager will wait until the end-user tells it to quit after showing the single line. Explicitly disable the pager with this "git show" invocation to fix this. The command uses the "--pretty=format:..." format, which adds LF in between each pair of commits it outputs, which means that the label for the merge being learned from will be followed by the next message on the same line. "--pretty=tformat:..." is what we should instead, which adds LF after each commit, or a more modern way to spell it, i.e. "--format=...". This existing breakage becomes easier to see, now we no longer use the pager. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-17Merge branch 'ab/complete-show-all-commands'Libravatar Junio C Hamano1-1/+12
The command line completion script (in contrib/) learned to complete all Git subcommands, including the ones that are normally hidden, when GIT_COMPLETION_SHOW_ALL_COMMANDS is used. * ab/complete-show-all-commands: completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDS completion tests: re-source git-completion.bash in a subshell
2022-02-17Merge branch 'js/scalar-global-options'Libravatar Junio C Hamano3-1/+39
Scalar update. * js/scalar-global-options: scalar: accept -C and -c options before the subcommand
2022-02-17Merge branch 'tk/subtree-merge-not-ff-only'Libravatar Junio C Hamano1-2/+2
When "git subtree" wants to create a merge, it used "git merge" and let it be affected by end-user's "merge.ff" configuration, which has been corrected. * tk/subtree-merge-not-ff-only: subtree: force merge commit
2022-02-16Merge branch 'ld/sparse-index-bash-completion'Libravatar Junio C Hamano1-8/+36
The command line completion (in contrib/) learns to complete arguments to give to "git sparse-checkout" command. * ld/sparse-index-bash-completion: completion: handle unusual characters for sparse-checkout completion: improve sparse-checkout cone mode directory completion completion: address sparse-checkout issues
2022-02-11Merge branch 'bc/csprng-mktemps'Libravatar Junio C Hamano1-1/+1
Pick a better random number generator and use it when we prepare temporary filenames. * bc/csprng-mktemps: wrapper: use a CSPRNG to generate random file names wrapper: add a helper to generate numbers from a CSPRNG
2022-02-08completion: handle unusual characters for sparse-checkoutLibravatar Lessley Dennington1-13/+11
Update the __gitcomp_directories method to de-quote and handle unusual characters in directory names. Although this initially involved an attempt to re-use the logic in __git_index_files, this method removed subdirectories (e.g. folder1/0/ became folder1/), so instead new custom logic was placed directly in the __gitcomp_directories method. Note there are two tests for this new functionality - one for spaces and accents and one for backslashes and tabs. The backslashes and tabs test uses FUNNYNAMES to avoid running on Windows. This is because: 1. Backslashes are explicitly not allowed in Windows file paths. 2. Although tabs appear to be allowed when creating a file in a Windows bash shell, they actually are not renderable (and appear as empty boxes in the shell). Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Co-authored-by: Lessley Dennington <lessleydennington@gmail.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Lessley Dennington <lessleydennington@gmail.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08completion: improve sparse-checkout cone mode directory completionLibravatar Lessley Dennington1-1/+31
Use new __gitcomp_directories method to complete directory names in cone mode sparse-checkouts. This method addresses the caveat of poor performance in monorepos from the previous commit (by completing only one level of directories). The unusual character caveat from the previous commit will be fixed by the final commit in this series. Co-authored-by: Elijah Newren <newren@gmail.com> Co-authored-by: Lessley Dennington <lessleydennington@gmail.com> Signed-off-by: Lessley Dennington <lessleydennington@gmail.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08completion: address sparse-checkout issuesLibravatar Lessley Dennington1-8/+8
Correct multiple issues with tab completion of the git sparse-checkout command. These issues were: 1. git sparse-checkout <TAB> previously resulted in an incomplete list of subcommands (it was missing reapply and add). 2. Subcommand options were not tab-completable. 3. git sparse-checkout set <TAB> and git sparse-checkout add <TAB> showed both file names and directory names. While this may be a less surprising behavior for non-cone mode, cone mode sparse checkouts should complete only directory names. Note that while the new strategy of just using git ls-tree to complete on directory names is simple and a step in the right direction, it does have some caveats. These are: 1. Likelihood of poor performance in large monorepos (as a result of recursively completing directory names). 2. Inability to handle paths containing unusual characters. These caveats will be fixed by subsequent commits in this series. Signed-off-by: Lessley Dennington <lessleydennington@gmail.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDSLibravatar Ævar Arnfjörð Bjarmason1-1/+12
Add a GIT_COMPLETION_SHOW_ALL_COMMANDS=1 configuration setting to go with the existing GIT_COMPLETION_SHOW_ALL=1 added in c099f579b98 (completion: add GIT_COMPLETION_SHOW_ALL env var, 2020-08-19). This will include plumbing commands such as "cat-file" in "git <TAB>" and "git c<TAB>" completion. Without/with this I have 134 and 243 completion with git <TAB>, respectively. It was already possible to do this by tweaking GIT_TESTING_PORCELAIN_COMMAND_LIST= from the outside, that testing variable was added in 84a97131065 (completion: let git provide the completable command list, 2018-05-20). Doing this before loading git-completion.bash worked: export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=builtins,main,list-mainporcelain,others,nohelpers,alias,list-complete,config)" But such testing variables are not meant to be used from the outside, and we make no guarantees that those internal won't change. So let's expose this as a dedicated configuration knob. It would be better to teach --list-cmds=* a new category which would include all of these groups, but that's a larger change that we can leave for some other time. 1. https://lore.kernel.org/git/CAGP6POJ9gwp+t-eP3TPkivBLLbNb2+qj=61Mehcj=1BgrVOSLA@mail.gmail.com/ Reported-by: Hongyi Zhao <hongyi.zhao@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-01subtree: force merge commitLibravatar Thomas Koutcher1-2/+2
When `merge.ff` is set to `only` in .gitconfig, `git subtree pull` will fail with error `fatal: Not possible to fast-forward, aborting.`, but the command does want to make merges in these places. Add `--no-ff` argument to `git merge` to enforce this behaviour. Signed-off-by: Thomas Koutcher <thomas.koutcher@online.fr> Reviewed-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28scalar: accept -C and -c options before the subcommandLibravatar Johannes Schindelin3-1/+39
The `git` executable has these two very useful options: -C <directory>: switch to the specified directory before performing any actions -c <key>=<value>: temporarily configure this setting for the duration of the specified scalar subcommand With this commit, we teach the `scalar` executable the same trick. Note: It might look like a good idea to try to reuse the `handle_options()` function in `git.c` instead of replicating only the `-c`/`-C` part. However, that function is not only not in `libgit.a`, it is also intricately entangled with the rest of the code in `git.c` that is necessary e.g. to handle `--paginate`. Besides, no other option handled by that `handle_options()` function is relevant to Scalar, therefore the cost of refactoring vastly would outweigh the benefit. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-17wrapper: add a helper to generate numbers from a CSPRNGLibravatar brian m. carlson1-1/+1
There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>