summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2022-03-23bundle: move capabilities to end of 'verify'Libravatar Derrick Stolee1-5/+5
The 'filter' capability was added in 105c6f14a (bundle: parse filter capability, 2022-03-09), but was added in a strange place in the 'git bundle verify' output. The tests for this show output like the following: The bundle contains these 2 refs: <COMMIT1> <REF1> <COMMIT2> <REF2> The bundle uses this filter: blob:none The bundle records a complete history. This looks very odd if we have a thin bundle that contains boundary commits instead of a complete history: The bundle contains these 2 refs: <COMMIT1> <REF1> <COMMIT2> <REF2> The bundle uses this filter: blob:none The bundle requires these 2 refs: <COMMIT3> <COMMIT4> This separation between tip refs and boundary refs is unfortunate. Move the filter capability output to the end of the output. Update the documentation to match. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-21The thirteenth batchLibravatar Junio C Hamano1-0/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-21Merge branch 'ds/partial-bundles'Libravatar Junio C Hamano4-33/+37
Bundle file format gets extended to allow a partial bundle, filtered by similar criteria you would give when making a partial/lazy clone. * ds/partial-bundles: clone: fail gracefully when cloning filtered bundle bundle: unbundle promisor packs bundle: create filtered bundles rev-list: move --filter parsing into revision.c bundle: parse filter capability list-objects: handle NULL function pointers MyFirstObjectWalk: update recommended usage list-objects: consolidate traverse_commit_list[_filtered] pack-bitmap: drop filter in prepare_bitmap_walk() pack-objects: use rev.filter when possible revision: put object filter into struct rev_info list-objects-filter-options: create copy helper index-pack: document and test the --promisor option
2022-03-16The twelfth batchLibravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-16Merge branch 'ds/commit-graph-gen-v2-fixes'Libravatar Junio C Hamano1-2/+10
Fixes to the way generation number v2 in the commit-graph files are (not) handled. * ds/commit-graph-gen-v2-fixes: commit-graph: declare bankruptcy on GDAT chunks commit-graph: fix generation number v2 overflow values commit-graph: start parsing generation v2 (again) commit-graph: fix ordering bug in generation numbers t5318: extract helpers to lib-commit-graph.sh test-read-graph: include extra post-parse info
2022-03-16Merge branch 'tb/rename-remote-progress'Libravatar Junio C Hamano1-1/+1
"git remote rename A B", depending on the number of remote-tracking refs involved, takes long time renaming them. The command has been taught to show progress bar while making the user wait. * tb/rename-remote-progress: builtin/remote.c: show progress when renaming remote references builtin/remote.c: parse options in 'rename'
2022-03-13The eleventh batchLibravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-13Merge branch 'nj/read-tree-doc-reffix'Libravatar Junio C Hamano1-2/+2
Documentation mark-up fix. * nj/read-tree-doc-reffix: Documentation: git-read-tree: separate links using commas
2022-03-13Merge branch 'ab/make-optim-noop'Libravatar Junio C Hamano1-57/+6
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-09The tenth batchLibravatar Junio C Hamano1-1/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09Merge branch 'ab/help-fixes'Libravatar Junio C Hamano1-4/+11
Updates to how command line options to "git help" are handled. * ab/help-fixes: help: don't print "\n" before single-section output help: add --no-[external-commands|aliases] for use with --all help: error if [-a|-g|-c] and [-i|-m|-w] are combined help: correct usage & behavior of "git help --all" help: note the option name on option incompatibility help.c: split up list_all_cmds_help() function help tests: test "git" and "git help [-a|-g] spacing help.c: use puts() instead of printf{,_ln}() for consistency help doc: add missing "]" to "[-a|--all]"
2022-03-09Merge branch 'ab/c99-variadic-macros'Libravatar Junio C Hamano1-0/+3
Remove the escape hatch we added when we introduced the weather balloon to use variadic macros unconditionally, to make it official that we now have a hard dependency on the feature. * ab/c99-variadic-macros: C99: remove hardcoded-out !HAVE_VARIADIC_MACROS code git-compat-util.h: clarify GCC v.s. C99-specific in comment
2022-03-09Merge branch 'hn/reftable-no-empty-keys'Libravatar Junio C Hamano1-1/+1
General clean-up in reftable implementation, including clarification of the API documentation, tightening the code to honor documented length limit, etc. * hn/reftable-no-empty-keys: reftable: rename writer_stats to reftable_writer_stats reftable: add test for length of disambiguating prefix reftable: ensure that obj_id_len is >= 2 on writing reftable: avoid writing empty keys at the block layer reftable: add a test that verifies that writing empty keys fails reftable: reject 0 object_id_len Documentation: object_id_len goes up to 31
2022-03-09Merge branch 'jc/cat-file-batch-commands'Libravatar Junio C Hamano1-4/+38
"git cat-file" learns "--batch-command" mode, which is a more flexible interface than the existing "--batch" or "--batch-check" modes, to allow different kinds of inquiries made. * jc/cat-file-batch-commands: cat-file: add --batch-command mode cat-file: add remove_timestamp helper cat-file: introduce batch_mode enum to replace print_contents cat-file: rename cmdmode to transform_mode
2022-03-09Merge branch 'en/present-despite-skipped'Libravatar Junio C Hamano5-47/+127
In sparse-checkouts, files mis-marked as missing from the working tree could lead to later problems. Such files were hard to discover, and harder to correct. Automatically detecting and correcting the marking of such files has been added to avoid these problems. * en/present-despite-skipped: repo_read_index: add config to expect files outside sparse patterns Accelerate clear_skip_worktree_from_present_files() by caching Update documentation related to sparsity and the skip-worktree bit repo_read_index: clear SKIP_WORKTREE bit from files present in worktree unpack-trees: fix accidental loss of user changes t1011: add testcase demonstrating accidental loss of user modifications
2022-03-09bundle: parse filter capabilityLibravatar Derrick Stolee2-5/+13
The v3 bundle format has capabilities, allowing newer versions of Git to create bundles with newer features. Older versions that do not understand these new capabilities will fail with a helpful warning. Create a new capability allowing Git to understand that the contained pack-file is filtered according to some object filter. Typically, this filter will be "blob:none" for a blobless partial clone. This change teaches Git to parse this capability, place its value in the bundle header, and demonstrate this understanding by adding a message to 'git bundle verify'. Since we will use gently_parse_list_objects_filter() outside of list-objects-filter-options.c, make it an external method and move its API documentation to before its declaration. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09MyFirstObjectWalk: update recommended usageLibravatar Derrick Stolee1-28/+16
The previous change consolidated traverse_commit_list() and traverse_commit_list_filtered(). This allows us to simplify the recommended usage in MyFirstObjectWalk.txt to use this new set of values. While here, add some clarification on the difference between the two methods. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-09index-pack: document and test the --promisor optionLibravatar Derrick Stolee1-0/+8
The --promisor option of 'git index-pack' was created in 88e2f9e (introduce fetch-object: fetch one promisor object, 2017-12-05) but was untested. It is currently unused within the Git codebase, but that will change in an upcoming change to 'git bundle unbundle' when there is a filter capability. For now, add documentation about the option and add a test to ensure it is working as expected. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07commit-graph: declare bankruptcy on GDAT chunksLibravatar Derrick Stolee1-2/+10
The Generation Data (GDAT) and Generation Data Overflow (GDOV) chunks store corrected commit date offsets, used for generation number v2. Recent changes have demonstrated that previous versions of Git were incorrectly parsing data from these chunks, but might have also been writing them incorrectly. I asserted [1] that the previous fixes were sufficient because the known reasons for incorrectly writing generation number v2 data relied on parsing the information incorrectly out of a commit-graph file, but the previous versions of Git were not reading the generation number v2 data. However, Patrick demonstrated [2] a case where in split commit-graphs across an alternate boundary (and possibly some other special conditions) it was possible to have a commit-graph that was generated by a previous version of Git have incorrect generation number v2 data which results in errors like the following: commit-graph generation for commit <oid> is 1623273624 < 1623273710 [1] https://lore.kernel.org/git/f50e74f0-9ffa-f4f2-4663-269801495ed3@github.com/ [2] https://lore.kernel.org/git/Yh93vOkt2DkrGPh2@ncase/ Clearly, there is something else going on. The situation is not completely understood, but the errors do not reproduce if the commit-graphs are all generated by a Git version including these recent fixes. If we cannot trust the existing data in the GDAT and GDOV chunks, then we can alter the format to change the chunk IDs for these chunks. This causes the new version of Git to silently ignore the older chunks (and disabling generation number v2 in the process) while writing new commit-graph files with correct data in the GDA2 and GDO2 chunks. Update commit-graph-format.txt including a historical note about these deprecated chunks. Reported-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-06The ninth batchLibravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-06Merge branch 'jt/ls-files-stage-recurse'Libravatar Junio C Hamano1-1/+1
Many output modes of "ls-files" do not work with its "--recurse-submodules" option, but the "-s" mode has been taught to work with it. * jt/ls-files-stage-recurse: ls-files: support --recurse-submodules --stage
2022-03-06Merge branch 'ah/advice-switch-requires-detach-to-detach'Libravatar Junio C Hamano1-0/+3
The error message given by "git switch HEAD~4" has been clarified to suggest the "--detach" option that is required. * ah/advice-switch-requires-detach-to-detach: switch: mention the --detach option when dying due to lack of a branch
2022-03-06Merge branch 'ds/worktree-docs'Libravatar Junio C Hamano1-134/+134
Tighten the language around "working tree" and "worktree" in the docs. * ds/worktree-docs: worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: use 'worktree' over 'working tree' worktree: extract checkout_worktree() worktree: extract copy_sparse_checkout() worktree: extract copy_filtered_worktree_config() worktree: combine two translatable messages
2022-03-03builtin/remote.c: show progress when renaming remote referencesLibravatar Taylor Blau1-1/+1
When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03Documentation: git-read-tree: separate links using commasLibravatar Nihal Jere1-2/+2
This makes it consistent with the rest of the documentation. Signed-off-by: Nihal Jere <nihal@nihaljere.xyz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03Makefiles: add and use wildcard "mkdir -p" templateLibravatar Ævar Arnfjörð Bjarmason1-22/+3
Add a template to do the "mkdir -p" of $(@D) (the parent dir of $@) for us, and use it for the "make lint-docs" targets I added in 8650c6298c1 (doc lint: make "lint-docs" non-.PHONY, 2021-10-15). As seen in 4c64fb5aad9 (Documentation/Makefile: fix lint-docs mkdir dependency, 2021-10-26) maintaining these manual lists of parent directory dependencies is fragile, in addition to being obviously verbose. I used this pattern at the time because I couldn't find another method than "order-only" prerequisites to avoid doing a "mkdir -p $(@D)" for every file being created, which as noted in [1] would be significantly slower. But as it turns out we can use this neat trick of only doing a "mkdir -p" if the $(wildcard) macro tells us the path doesn't exist. A re-run of a performance test similar to that noted downthread of [1] in [2] shows that this is faster, in addition to being less verbose and more reliable (this uses my "git-hyperfine" thin wrapper for "hyperfine"[3]): $ git -c hyperfine.hook.setup= hyperfine -L rev HEAD~1,HEAD~0 -s 'make -C Documentation lint-docs' -p 'rm -rf Documentation/.build' 'make -C Documentation -j1 lint-docs' Benchmark 1: make -C Documentation -j1 lint-docs' in 'HEAD~1 Time (mean ± σ): 2.914 s ± 0.062 s [User: 2.449 s, System: 0.489 s] Range (min … max): 2.834 s … 3.020 s 10 runs Benchmark 2: make -C Documentation -j1 lint-docs' in 'HEAD~0 Time (mean ± σ): 2.315 s ± 0.062 s [User: 1.950 s, System: 0.386 s] Range (min … max): 2.229 s … 2.397 s 10 runs Summary 'make -C Documentation -j1 lint-docs' in 'HEAD~0' ran 1.26 ± 0.04 times faster than 'make -C Documentation -j1 lint-docs' in 'HEAD~1' So let's use that pattern both for the "lint-docs" target, and a few miscellaneous other targets. This method of creating parent directories is explicitly racy in that we don't know if we're going to say always create a "foo" followed by a "foo/bar" under parallelism, or skip the "foo" because we created "foo/bar" first. In this case it doesn't matter for anything except that we aren't guaranteed to get the same number of rules firing when running make in parallel. 1. https://lore.kernel.org/git/211028.861r45y3pt.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/211028.86o879vvtp.gmgdl@evledraar.gmail.com/ 3. https://gitlab.com/avar/git-hyperfine/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03Makefile: add "$(QUIET)" boilerplate to shared.makLibravatar Ævar Arnfjörð Bjarmason1-32/+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ð Bjarmason1-3/+3
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-01repo_read_index: add config to expect files outside sparse patternsLibravatar Elijah Newren2-0/+29
Typically with sparse checkouts, we expect files outside the sparsity patterns to be marked as SKIP_WORKTREE and be missing from the working tree. Sometimes this expectation would be violated however; including in cases such as: * users grabbing files from elsewhere and writing them to the worktree (perhaps by editing a cached copy in an editor, copying/renaming, or even untarring) * various git commands having incomplete or no support for the SKIP_WORKTREE bit[1,2] * users attempting to "abort" a sparse-checkout operation with a not-so-early Ctrl+C (updating $GIT_DIR/info/sparse-checkout and the working tree is not atomic)[3]. When the SKIP_WORKTREE bit in the index did not reflect the presence of the file in the working tree, it traditionally caused confusion and was difficult to detect and recover from. So, in a sparse checkout, since af6a51875a (repo_read_index: clear SKIP_WORKTREE bit from files present in worktree, 2022-01-14), Git automatically clears the SKIP_WORKTREE bit at index read time for entries corresponding to files that are present in the working tree. There is another workflow, however, where it is expected that paths outside the sparsity patterns appear to exist in the working tree and that they do not lose the SKIP_WORKTREE bit, at least until they get modified. A Git-aware virtual file system[4] takes advantage of its position as a file system driver to expose all files in the working tree, fetch them on demand using partial clone on access, and tell Git to pay attention to them on demand by updating the sparse checkout pattern on writes. This means that commands like "git status" only have to examine files that have potentially been modified, whereas commands like "ls" are able to show the entire codebase without requiring manual updates to the sparse checkout pattern. Thus since af6a51875a, Git with such Git-aware virtual file systems unsets the SKIP_WORKTREE bit for all files and commands like "git status" have to fetch and examine them all. Introduce a configuration setting sparse.expectFilesOutsideOfPatterns to allow limiting the tracked set of files to a small set once again. A Git-aware virtual file system or other application that wants to maintain files outside of the sparse checkout can set this in a repository to instruct Git not to check for the presence of SKIP_WORKTREE files. The setting defaults to false, so most users of sparse checkout will still get the benefit of an automatically updating index to recover from the variety of difficult issues detailed in af6a51875a for paths with SKIP_WORKTREE set despite the path being present. [1] https://lore.kernel.org/git/xmqqbmb1a7ga.fsf@gitster-ct.c.googlers.com/ [2] The three long paragraphs in the middle of https://lore.kernel.org/git/CABPp-BH9tju7WVm=QZDOvaMDdZbpNXrVWQdN-jmfN8wC6YVhmw@mail.gmail.com/ [3] https://lore.kernel.org/git/CABPp-BFnFpzwGC11TLoLs8YK5yiisA5D5-fFjXnJsbESVDwZsA@mail.gmail.com/ [4] such as the vfsd described in https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/ Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25switch: mention the --detach option when dying due to lack of a branchLibravatar Alex Henrie1-0/+3
Users who are accustomed to doing `git checkout <tag>` assume that `git switch <tag>` will do the same thing. Inform them of the --detach option so they aren't left wondering why `git switch` doesn't work but `git checkout` does. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25The eighth batchLibravatar Junio C Hamano1-0/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25Merge branch 'js/apply-partial-clone-filters-recursively'Libravatar Junio C Hamano3-2/+16
"git clone --filter=... --recurse-submodules" only makes the top-level a partial clone, while submodules are fully cloned. This behaviour is changed to pass the same filter down to the submodules. * js/apply-partial-clone-filters-recursively: clone, submodule: pass partial clone filters to submodules
2022-02-25Merge branch 'ds/sparse-checkout-requires-per-worktree-config'Libravatar Junio C Hamano4-9/+57
"git sparse-checkout" wants to work with per-worktree configuration, but did not work well in a worktree attached to a bare repository. * ds/sparse-checkout-requires-per-worktree-config: config: make git_configset_get_string_tmp() private worktree: copy sparse-checkout patterns and config on add sparse-checkout: set worktree-config correctly config: add repo_config_set_worktree_gently() worktree: create init_worktree_config() Documentation: add extensions.worktreeConfig details
2022-02-23The seventh batchLibravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23Merge branch 'bc/clarify-eol-attr'Libravatar Junio C Hamano1-5/+6
Documentation update * bc/clarify-eol-attr: doc: clarify interaction between 'eol' and text=auto
2022-02-23ls-files: support --recurse-submodules --stageLibravatar Jonathan Tan1-1/+1
e77aa336f1 ("ls-files: optionally recurse into submodules", 2016-10-10) taught ls-files the --recurse-submodules argument, but only in a limited set of circumstances. In particular, --stage was unsupported, perhaps because there was no repo_find_unique_abbrev(), which was only introduced in 8bb95572b0 ("sha1-name.c: add repo_find_unique_abbrev_r()", 2019-04-16). This function is needed for using --recurse-submodules with --stage. Now that we have repo_find_unique_abbrev(), teach support for this combination of arguments. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23help: add --no-[external-commands|aliases] for use with --allLibravatar Ævar Arnfjörð Bjarmason1-1/+9
Add the ability to only emit git's own usage information under --all. This also allows us to extend the "test_section_spacing" tests added in a preceding commit to test "git help --all" output. Previously we could not do that, as the tests might find a git-* command in the "$PATH", which would make the output differ from one setup to another. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23help: correct usage & behavior of "git help --all"Libravatar Ævar Arnfjörð Bjarmason1-3/+2
Do the same for the "--all" option that I did for "--guides" in 9856ea6785c (help: correct usage & behavior of "git help --guides", 2021-09-22). I.e. we've documented it as ignoring non-option arguments, let's have it error out instead. As with other changes made in 62f035aee3f (Merge branch 'ab/help-config-vars', 2021-10-13) this is technically a change in behavior, but in practice it's just a bug fix. We were ignoring this before, but by erroring we can simplify our documentation and synopsis, as well as avoid user confusion as they wonder what the difference between e.g. "git help --all" and "git help --all status" is (there wasn't any difference). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23help doc: add missing "]" to "[-a|--all]"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Add a missing "]" to documentation added in 63eae83f8f3 (help: add "-a --verbose" to list all commands with synopsis, 2018-05-20). This made it seem as though "--[no-]verbose" can only be provided with "--all", not "-a". The corresponding usage information in the C code ("builtin_help_usage") does not have the same problem. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23Documentation: object_id_len goes up to 31Libravatar Han-Wen Nienhuys1-1/+1
The value is stored in a 5-bit field, so we can't support more without a format version upgrade. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-7/+7
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the last of multiple changes to git-worktree.txt, starting at the LIST OUTPUT FORMAT section. The EXAMPLES section has an instance of "working tree" that must stay as it is, because it is not talking about a worktree, but an example of why a user might want to create a worktree. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-12/+12
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the sixth of multiple changes to git-worktree.txt, restricted to the DETAILS section. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-11/+11
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the fifth of multiple changes to git-worktree.txt, restricted to the CONFIGURATION FILE section. While here, clear up some language to improve readability. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-16/+15
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the fourth of multiple changes to git-worktree.txt, restricted to the REFS section. This section previously described "per working tree" refs but they are now replaced with "per-worktree" refs, which matches the definition in glossary-content.txt. The first paragraph of this section was also a bit confusing, so it is cleaned up to make it easier to understand. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-21/+21
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the third of multiple changes to git-worktree.txt, restricted to the OPTIONS section. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-44/+41
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the second of multiple changes to git-worktree.txt, restricted to the COMMANDS section. There is some language around the movement of "the working tree of a linked worktree" which is used once, but the remaining uses are left as just moving "a linked worktree" for brevity. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-23/+27
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the first of multiple changes to git-worktree.txt, restricted to the DESCRIPTION section. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-21C99: remove hardcoded-out !HAVE_VARIADIC_MACROS codeLibravatar Ævar Arnfjörð Bjarmason1-0/+3
Remove the "else" branches of the HAVE_VARIADIC_MACROS macro, which have been unconditionally omitted since 765dc168882 (git-compat-util: always enable variadic macros, 2021-01-28). Since were always omitted, anyone trying to use a compiler without variadic macro support to compile a git since version git v2.31.0 or later would have had a compilation error. 10 months across a few releases since then should have been enough time for anyone who cared to run into that and report the issue. In addition to that, for anyone unsetting HAVE_VARIADIC_MACROS we've been emitting extremely verbose warnings since at least ee4512ed481 (trace2: create new combined trace facility, 2019-02-22). That's because there is no such thing as a "region_enter_printf" or "region_leave_printf" format, so at least under GCC and Clang everything that includes trace.h (almost every file) emits a couple of warnings about that. There's a large benefit to being able to have a hard dependency rely on variadic macros, the code surrounding usage.c is hard to maintain if we need to write two implementations of everything, and by relying on "__FILE__" and "__LINE__" along with "__VA_ARGS__" we can in the future make error(), die() etc. log where they were called from. We've also recently merged d67fc4bf0ba (Merge branch 'bc/require-c99', 2021-12-10) which further cements our hard dependency on C99. So let's delete the fallback code, and update our CodingGuidelines to note that we depend on this. The added bullet-point starts with lower-case for consistency with other bullet-points in that section. The diff in "trace.h" is relatively hard to read, since we need to retain the existing API docs, which were comments on the code used if HAVE_VARIADIC_MACROS was not defined. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-18The sixth batchLibravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-18Merge branch 'jc/glossary-worktree'Libravatar Junio C Hamano1-2/+11
"working tree" and "per-worktree ref" were in glossary, but "worktree" itself wasn't, which has been corrected. * jc/glossary-worktree: glossary: describe "worktree"