summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2022-02-18Merge branch 'gc/branch-recurse-submodules'Libravatar Junio C Hamano3-12/+47
"git branch" learned the "--recurse-submodules" option. * gc/branch-recurse-submodules: branch.c: use 'goto cleanup' in setup_tracking() to fix memory leaks branch: add --recurse-submodules option for branch creation builtin/branch: consolidate action-picking logic in cmd_branch() branch: add a dry_run parameter to create_branch() branch: make create_branch() always create a branch branch: move --set-upstream-to behavior to dwim_and_setup_tracking()
2022-02-17The fifth batchLibravatar Junio C Hamano1-0/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-17Merge branch 'po/doc-check-ignore-markup-fix'Libravatar Junio C Hamano1-2/+2
Typofix. * po/doc-check-ignore-markup-fix: doc: check-ignore: code-quote an exclamation mark
2022-02-17Merge branch 'vd/sparse-clean-etc'Libravatar Junio C Hamano1-2/+8
"git update-index", "git checkout-index", and "git clean" are taught to work better with the sparse checkout feature. * vd/sparse-clean-etc: update-index: reduce scope of index expansion in do_reupdate update-index: integrate with sparse index update-index: add tests for sparse-checkout compatibility checkout-index: integrate with sparse index checkout-index: add --ignore-skip-worktree-bits option checkout-index: expand sparse checkout compatibility tests clean: integrate with sparse index reset: reorder wildcard pathspec conditions reset: fix validation in sparse index test
2022-02-17Merge branch 'jz/rev-list-exclude-first-parent-only'Libravatar Junio C Hamano1-7/+15
"git log" and friends learned an option --exclude-first-parent-only to propagate UNINTERESTING bit down only along the first-parent chain, just like --first-parent option shows commits that lack the UNINTERESTING bit only along the first-parent chain. * jz/rev-list-exclude-first-parent-only: git-rev-list: add --exclude-first-parent-only flag
2022-02-16The fourth batchLibravatar Junio C Hamano1-0/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-16Merge branch 'js/no-more-legacy-stash'Libravatar Junio C Hamano1-7/+0
Removal of unused code and doc. * js/no-more-legacy-stash: stash: stop warning about the obsolete `stash.useBuiltin` config setting stash: remove documentation for `stash.useBuiltin` add: remove support for `git-legacy-stash` git-sh-setup: remove remnant bits referring to `git-legacy-stash`
2022-02-16Merge branch 'js/diff-filter-negation-fix'Libravatar Junio C Hamano1-5/+2
"git diff --diff-filter=aR" is now parsed correctly. * js/diff-filter-negation-fix: diff-filter: be more careful when looking for negative bits diff.c: move the diff filter bits definitions up a bit docs(diff): lose incorrect claim about `diff-files --diff-filter=A`
2022-02-16Merge branch 'en/fetch-negotiation-default-fix'Libravatar Junio C Hamano1-12/+13
Interaction between fetch.negotiationAlgorithm and feature.experimental configuration variables has been corrected. * en/fetch-negotiation-default-fix: repo-settings: rename the traditional default fetch.negotiationAlgorithm repo-settings: fix error handling for unknown values repo-settings: fix checking for fetch.negotiationAlgorithm=default
2022-02-16Merge branch 'tb/midx-bitmap-corruption-fix'Libravatar Junio C Hamano2-6/+8
A bug that made multi-pack bitmap and the object order out-of-sync, making the .midx data corrupt, has been fixed. * tb/midx-bitmap-corruption-fix: pack-bitmap.c: gracefully fallback after opening pack/MIDX midx: read `RIDX` chunk when present t/lib-bitmap.sh: parameterize tests over reverse index source t5326: move tests to t/lib-bitmap.sh t5326: extract `test_rev_exists` t5326: drop unnecessary setup pack-revindex.c: instrument loading on-disk reverse index midx.c: make changing the preferred pack safe t5326: demonstrate bitmap corruption after permutation
2022-02-16Merge branch 'en/remerge-diff'Libravatar Junio C Hamano1-1/+13
"git log --remerge-diff" shows the difference from mechanical merge result and the result that is actually recorded in a merge commit. * en/remerge-diff: diff-merges: avoid history simplifications when diffing merges merge-ort: mark conflict/warning messages from inner merges as omittable show, log: include conflict/warning messages in --remerge-diff headers diff: add ability to insert additional headers for paths merge-ort: format messages slightly different for use in headers merge-ort: mark a few more conflict messages as omittable merge-ort: capture and print ll-merge warnings in our preferred fashion ll-merge: make callers responsible for showing warnings log: clean unneeded objects during `log --remerge-diff` show, log: provide a --remerge-diff capability
2022-02-16Merge branch 'll/doc-mktree-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * ll/doc-mktree-typofix: fix typo in git-mktree.txt
2022-02-11The third batchLibravatar Junio C Hamano1-0/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-11Merge branch 'jc/doc-log-messages'Libravatar Junio C Hamano2-0/+43
Update the contributor-facing documents on proposed log messages. * jc/doc-log-messages: SubmittingPatches: explain why we care about log messages CodingGuidelines: hint why we value clearly written log messages SubmittingPatches: write problem statement in the log in the present tense
2022-02-11Merge branch 'gh/doc-typos'Libravatar Junio C Hamano1-2/+2
Typofix. * gh/doc-typos: Documentation/config/pgp.txt: add missing apostrophe Documentation/config/pgp.txt: replace stray <TAB> character with <SPC>
2022-02-11Merge branch 'bc/clarify-eol-attr'Libravatar Junio C Hamano1-5/+6
Doc and test update around the eol attribute. * bc/clarify-eol-attr: docs: correct documentation about eol attribute t0027: add tests for eol without text in .gitattributes
2022-02-09The second batch for 2.36Libravatar Junio C Hamano1-1/+59
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-09Merge branch 'ab/config-based-hooks-2'Libravatar Junio C Hamano2-0/+49
More "config-based hooks". * ab/config-based-hooks-2: run-command: remove old run_hook_{le,ve}() hook API receive-pack: convert push-to-checkout hook to hook.h read-cache: convert post-index-change to use hook.h commit: convert {pre-commit,prepare-commit-msg} hook to hook.h git-p4: use 'git hook' to run hooks send-email: use 'git hook run' for 'sendemail-validate' git hook run: add an --ignore-missing flag hooks: convert worktree 'post-checkout' hook to hook library hooks: convert non-worktree 'post-checkout' hook to hook library merge: convert post-merge to use hook.h am: convert applypatch-msg to use hook.h rebase: convert pre-rebase to use hook.h hook API: add a run_hooks_l() wrapper am: convert {pre,post}-applypatch to use hook.h gc: use hook library for pre-auto-gc hook hook API: add a run_hooks() wrapper hook: add 'run' subcommand
2022-02-09Merge branch 'jc/name-rev-stdin'Libravatar Junio C Hamano1-2/+28
"git name-rev --stdin" does not behave like usual "--stdin" at all. Start the process of renaming it to "--annotate-stdin". * jc/name-rev-stdin: name-rev.c: use strbuf_getline instead of limited size buffer name-rev: deprecate --stdin in favor of --annotate-stdin
2022-02-09Merge branch 'gc/fetch-negotiate-only-early-return'Libravatar Junio C Hamano1-0/+1
"git fetch --negotiate-only" is an internal command used by "git push" to figure out which part of our history is missing from the other side. It should never recurse into submodules even when fetch.recursesubmodules configuration variable is set, nor it should trigger "gc". The code has been tightened up to ensure it only does common ancestry discovery and nothing else. * gc/fetch-negotiate-only-early-return: fetch: help translators by reusing the same message template fetch --negotiate-only: do not update submodules fetch: skip tasks related to fetching objects fetch: use goto cleanup in cmd_fetch()
2022-02-09Merge branch 'tl/doc-cli-options-first'Libravatar Junio C Hamano1-5/+14
We explain that revs come first before the pathspec among command line arguments, but did not spell out that dashed options come before other args, which has been corrected. * tl/doc-cli-options-first: git-cli.txt: clarify "options first and then args"
2022-02-09Merge branch 'jt/conditional-config-on-remote-url'Libravatar Junio C Hamano1-0/+35
The conditional inclusion mechanism of configuration files using "[includeIf <condition>]" learns to base its decision on the URL of the remote repository the repository interacts with. * jt/conditional-config-on-remote-url: config: include file if remote URL matches a glob config: make git_config_include() static
2022-02-05The first batchLibravatar Junio C Hamano1-3/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-05Merge branch 'ab/cat-file'Libravatar Junio C Hamano1-2/+8
Assorted updates to "git cat-file", especially "-h". * ab/cat-file: cat-file: s/_/-/ in typo'd usage_msg_optf() message cat-file: don't whitespace-pad "(...)" in SYNOPSIS and usage output cat-file: use GET_OID_ONLY_TO_DIE in --(textconv|filters) object-name.c: don't have GET_OID_ONLY_TO_DIE imply *_QUIETLY cat-file: correct and improve usage information cat-file: fix remaining usage bugs cat-file: make --batch-all-objects a CMDMODE cat-file: move "usage" variable to cmd_cat_file() cat-file docs: fix SYNOPSIS and "-h" output parse-options API: add a usage_msg_optf() cat-file tests: test messaging on bad objects/paths cat-file tests: test bad usage
2022-02-04branch: add --recurse-submodules option for branch creationLibravatar Glen Choo3-12/+47
To improve the submodules UX, we would like to teach Git to handle branches in submodules. Start this process by teaching "git branch" the --recurse-submodules option so that "git branch --recurse-submodules topic" will create the `topic` branch in the superproject and its submodules. Although this commit does not introduce breaking changes, it does not work well with existing --recurse-submodules commands because "git branch --recurse-submodules" writes to the submodule ref store, but most commands only consider the superproject gitlink and ignore the submodule ref store. For example, "git checkout --recurse-submodules" will check out the commits in the superproject gitlinks (and put the submodules in detached HEAD) instead of checking out the submodule branches. Because of this, this commit introduces a new configuration value, `submodule.propagateBranches`. The plan is for Git commands to prioritize submodule ref store information over superproject gitlinks if this value is true. Because "git branch --recurse-submodules" writes to submodule ref stores, for the sake of clarity, it will not function unless this configuration value is set. This commit also includes changes that support working with submodules from a superproject commit because "branch --recurse-submodules" (and future commands) need to read .gitmodules and gitlinks from the superproject commit, but submodules are typically read from the filesystem's .gitmodules and the index's gitlinks. These changes are: * add a submodules_of_tree() helper that gives the relevant information of an in-tree submodule (e.g. path and oid) and initializes the repository * add is_tree_submodule_active() by adding a treeish_name parameter to is_submodule_active() * add the "submoduleNotUpdated" advice to advise users to update the submodules in their trees Incidentally, fix an incorrect usage string that combined the 'list' usage of git branch (-l) with the 'create' usage; this string has been incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use parse_options., 2007-10-07). Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-03doc: check-ignore: code-quote an exclamation markLibravatar Philip Oakley1-2/+2
The plain quoted exclamation mark renders as italics in the Windows pdf help manual. Fix this with back-tick quoting and surrounding double quotes as exemplified by the gitignore.txt guide. While at it, fix the surrounding double quotes for the other special characters usages. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02fix typo in git-mktree.txtLibravatar Liginity Lee1-1/+1
fix a typo: change "as" to "a". Signed-off-by: Liginity Lee <liginity@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02show, log: provide a --remerge-diff capabilityLibravatar Elijah Newren1-1/+13
When this option is specified, we remerge all (two parent) merge commits and diff the actual merge commit to the automatically created version, in order to show how users removed conflict markers, resolved the different conflict versions, and potentially added new changes outside of conflict regions in order to resolve semantic merge problems (or, possibly, just to hide other random changes). This capability works by creating a temporary object directory and marking it as the primary object store. This makes it so that any blobs or trees created during the automatic merge are easily removable afterwards by just deleting all objects from the temporary object directory. There are a few ways that this implementation is suboptimal: * `log --remerge-diff` becomes slow, because the temporary object directory can fill with many loose objects while running * the log output can be muddied with misplaced "warning: cannot merge binary files" messages, since ll-merge.c unconditionally writes those messages to stderr while running instead of allowing callers to manage them. * important conflict and warning messages are simply dropped; thus for conflicts like modify/delete or rename/rename or file/directory which are not representable with content conflict markers, there may be no way for a user of --remerge-diff to know that there had been a conflict which was resolved (and which possibly motivated other changes in the merge commit). * when fixing the previous issue, note that some unimportant conflict and warning messages might start being included. We should instead make sure these remain dropped. Subsequent commits will address these issues. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02repo-settings: rename the traditional default fetch.negotiationAlgorithmLibravatar Elijah Newren1-12/+13
Give the traditional default fetch.negotiationAlgorithm the name 'consecutive'. Also allow a choice of 'default' to have Git decide between the choices (currently, picking 'skipping' if feature.experimental is true and 'consecutive' otherwise). Update the documentation accordingly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-31Merge branch 'js/branch-track-inherit' into gc/branch-recurse-submodulesLibravatar Junio C Hamano4-10/+21
* js/branch-track-inherit: branch,checkout: fix --track documentation branch,checkout: fix --track usage strings config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-28Sync with Git 2.35.1Libravatar Junio C Hamano1-0/+6
2022-01-28Name the next one 2.36 to prepare for 2.35.1Libravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Git 2.35.1Libravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28docs(diff): lose incorrect claim about `diff-files --diff-filter=A`Libravatar Johannes Schindelin1-5/+2
Originally, before we had `--intent-to-add`, there was no way that `git diff-files` could see added files: if a file did not exist in the index, `git diff-files` would not show it because it looks only at worktree files when there is an index entry at the same path. We used this example in the documentation of the diff options to explain that not every `--diff-filter=<option>` has an effect in all scenarios. Even when we added `--intent-to-add`, the comment was still correct, because initially we showed such files as modified instead of added. However, when that bug was fixed in feea6946a5b (diff-files: treat "i-t-a" files as "not-in-index", 2020-06-20), the comment in the documentation became incorrect. Let's just remove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27stash: remove documentation for `stash.useBuiltin`Libravatar Johannes Schindelin1-7/+0
In 8a2cd3f5123 (stash: remove the stash.useBuiltin setting, 2020-03-03), we removed the setting, and for a couple of major versions, we still documented the setting, telling users that it is gone. We can now safely remove even the documentation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27SubmittingPatches: explain why we care about log messagesLibravatar Junio C Hamano1-0/+29
Extend the "describe your changes well" section to cover whom we are trying to help by doing so in the first place. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27CodingGuidelines: hint why we value clearly written log messagesLibravatar Junio C Hamano1-0/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27SubmittingPatches: write problem statement in the log in the present tenseLibravatar Junio C Hamano1-0/+7
We give a guidance for proposed log message to write problem statement first, followed by the reasoning behind, and recipe for, the solution. Clarify that we describe the situation _before_ the proposed patch is applied in the present tense (not in the past tense e.g. "we used to do X, but thanks to this commit we now do Y") for consistency. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-27midx.c: make changing the preferred pack safeLibravatar Taylor Blau2-6/+8
The previous patch demonstrates a bug where a MIDX's auxiliary object order can become out of sync with a MIDX bitmap. This is because of two confounding factors: - First, the object order is stored in a file which is named according to the multi-pack index's checksum, and the MIDX does not store the object order. This means that the object order can change without altering the checksum. - But the .rev file is moved into place with finalize_object_file(), which link(2)'s the file into place instead of renaming it. For us, that means that a modified .rev file will not be moved into place if MIDX's checksum was unchanged. This fix is to force the MIDX's checksum to change when the preferred pack changes but the set of packs contained in the MIDX does not. In other words, when the object order changes, the MIDX's checksum needs to change with it (regardless of whether the MIDX is tracking the same or different packs). This prevents a race whereby changing the object order (but not the packs themselves) enables a reader to see the new .rev file with the old MIDX, or similarly seeing the new bitmap with the old object order. But why can't we just stop hardlinking the .rev into place instead adding additional data to the MIDX? Suppose that's what we did. Then when we go to generate the new bitmap, we'll load the old MIDX bitmap, along with the MIDX that it references. That's fine, since the new MIDX isn't moved into place until after the new bitmap is generated. But the new object order *has* been moved into place. So we'll read the old bitmaps in the new order when generating the new bitmap file, meaning that without this secondary change, bitmap generation itself would become a victim of the race described here. This can all be prevented by forcing the MIDX's checksum to change when the object order does. By embedding the entire object order into the MIDX, we do just that. That is, the MIDX's checksum will change in response to any perturbation of the underlying object order. In t5326, this will cause the MIDX's checksum to update (even without changing the set of packs in the MIDX), preventing the stale read problem. Note that this makes it safe to continue to link(2) the MIDX .rev file into place, since it is now impossible to have a .rev file that is out-of-sync with the MIDX whose checksum it references. (But we will do away with MIDX .rev files later in this series anyway, so this is somewhat of a moot point). In theory, it is possible to store a "fingerprint" of the full object order here, so long as that fingerprint changes at least as often as the full object order does. Some possibilities here include storing the identity of the preferred pack, along with the mtimes of the non-preferred packs in a consistent order. But storing a limited part of the information makes it difficult to reason about whether or not there are gaps between the two that would cause us to get bitten by this bug again. Signed-off-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Documentation/config/pgp.txt: add missing apostropheLibravatar Greg Hurrell1-1/+1
Add an apostrophe to "signatures" to indicate the possessive relationship in "the signature's creation". Signed-off-by: Greg Hurrell <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Documentation/config/pgp.txt: replace stray <TAB> character with <SPC>Libravatar Greg Hurrell1-1/+1
Specifically, replace the tab between "the" and "first" with a space. Signed-off-by: Greg Hurrell <greg@hurrell.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Git 2.35Libravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-20Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-7/+7
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. source: <3de40324bea6a1dd9bca2654721471e3809e87d8.1642538935.git.steadmon@google.com> source: <c3c26192-aee9-185a-e559-b8735139e49c@web.de> * js/branch-track-inherit: branch,checkout: fix --track documentation
2022-01-20branch,checkout: fix --track documentationLibravatar René Scharfe2-7/+7
Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18fetch --negotiate-only: do not update submodulesLibravatar Glen Choo1-0/+1
`git fetch --negotiate-only` is an implementation detail of push negotiation and, unlike most `git fetch` invocations, does not actually update the main repository. Thus it should not update submodules even if submodule recursion is enabled. This is not just slow, it is wrong e.g. push negotiation with "submodule.recurse=true" will cause submodules to be updated because it invokes `git fetch --negotiate-only`. Fix this by disabling submodule recursion if --negotiate-only was given. Since this makes --negotiate-only and --recurse-submodules incompatible, check for this invalid combination and die. This does not use the "goto cleanup" introduced in the previous commit because we want to recurse through submodules whenever a ref is fetched, and this can happen without introducing new objects. Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18config: include file if remote URL matches a globLibravatar Jonathan Tan1-0/+35
This is a feature that supports config file inclusion conditional on whether the repo has a remote with a URL that matches a glob. Similar to my previous work on remote-suggested hooks [1], the main motivation is to allow remote repo administrators to provide recommended configs in a way that can be consumed more easily (e.g. through a package installable by a package manager - it could, for example, contain a file to be included conditionally and a post-install script that adds the include directive to the system-wide config file). In order to do this, Git reruns the config parsing mechanism upon noticing the first URL-conditional include in order to find all remote URLs, and these remote URLs are then used to determine if that first and all subsequent includes are executed. Remote URLs are not allowed to be configued in any URL-conditionally-included file. [1] https://lore.kernel.org/git/cover.1623881977.git.jonathantanmy@google.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-17git-cli.txt: clarify "options first and then args"Libravatar Teng Long1-5/+14
There are some commands permit the user whether to provide options first before args, or the reverse order. For example: git push --dry-run <remote> <ref> And: git push <remote> <ref> --dry-run Both of them is supported, but some commands do not, for instance: git ls-remote --heads <remote> And: git ls-remote <remote> --heads If <remote> only has one ref and it's name is "refs/heads/--heads", you will get the same result, otherwise will not.This is because the former in the second example will parse "--heads" as an "option" which means to limit to only "refs/heads" when listing the remote references, the latter treat "--heads" as an argument which means to filter the result list with the given pattern. Therefore, we want to specify a bit more in "gitcli.txt" about the way we recommend and help to resolve the ambiguity around some git command usage. The related disscussions locate at [1]. By the way, there are some issues with lowercase letters in the document, which have been modified together. [1] https://public-inbox.org/git/cover.1642129840.git.dyroneteng@gmail.com/ Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-13checkout-index: add --ignore-skip-worktree-bits optionLibravatar Victoria Dye1-2/+8
Update `checkout-index` to no longer refresh files that have the `skip-worktree` bit set, exiting with an error if `skip-worktree` filenames are directly provided to `checkout-index`. The newly-added `--ignore-skip-worktree-bits` option provides a mechanism to replicate the old behavior, checking out *all* files specified (even those with `skip-worktree` enabled). The ability to toggle whether files should be checked-out based on `skip-worktree` already exists in `git checkout` and `git restore` (both of which have an `--ignore-skip-worktree-bits` option). The change to, by default, ignore `skip-worktree` files is especially helpful for sparse-checkout; it prevents inadvertent creation of files outside the sparse definition on disk and eliminates the need to expand a sparse index when using the `--all` option. Internal usage of `checkout-index` in `git stash` and `git filter-branch` do not make explicit use of files with `skip-worktree` enabled, so `--ignore-skip-worktree-bits` is not added to them. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-12Last minute fixes before -rc1Libravatar Junio C Hamano1-1/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-12git-rev-list: add --exclude-first-parent-only flagLibravatar Jerry Zhang1-7/+15
It is useful to know when a branch first diverged in history from some integration branch in order to be able to enumerate the user's local changes. However, these local changes can include arbitrary merges, so it is necessary to ignore this merge structure when finding the divergence point. In order to do this, teach the "rev-list" family to accept "--exclude-first-parent-only", which restricts the traversal of excluded commits to only follow first parent links. -A-----E-F-G--main \ / / B-C-D--topic In this example, the goal is to return the set {B, C, D} which represents a topic branch that has been merged into main branch. `git rev-list topic ^main` will end up returning no commits since excluding main will end up traversing the commits on topic as well. `git rev-list --exclude-first-parent-only topic ^main` however will return {B, C, D} as desired. Add docs for the new flag, and clarify the doc for --first-parent to indicate that it applies to traversing the set of included commits only. Signed-off-by: Jerry Zhang <jerry@skydio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>