summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2021-10-14Thirteenth batchLibravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-13Merge branch 'ja/doc-status-types-and-copies'Libravatar Junio C Hamano2-11/+14
A few kinds of changes "git status" can show were not documented. * ja/doc-status-types-and-copies: Documentation/git-status: mention how to detect copies Documentation/git-status: document porcelain status T (typechange) Documentation/diff-format: state in which cases porcelain status is T Documentation/git-status: remove impossible porcelain status DR and DC
2021-10-13Merge branch 'ab/align-parse-options-help'Libravatar Junio C Hamano1-2/+2
When "git cmd -h" shows more than one line of usage text (e.g. the cmd subcommand may take sub-sub-command), parse-options API learned to align these lines, even across i18n/l10n. * ab/align-parse-options-help: parse-options: properly align continued usage output git rev-parse --parseopt tests: add more usagestr tests send-pack: properly use parse_options() API for usage string parse-options API users: align usage output in C-strings
2021-10-13Merge branch 'ab/help-config-vars'Libravatar Junio C Hamano1-4/+5
Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation
2021-10-13Merge branch 'jh/builtin-fsmonitor-part1'Libravatar Junio C Hamano1-0/+40
Built-in fsmonitor (part 1). * jh/builtin-fsmonitor-part1: t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command run-command: create start_bg_command simple-ipc/ipc-win32: add Windows ACL to named pipe simple-ipc/ipc-win32: add trace2 debugging simple-ipc: move definition of ipc_active_state outside of ifdef simple-ipc: preparations for supporting binary messages. trace2: add trace2_child_ready() to report on background children
2021-10-13Merge branch 'en/removing-untracked-fixes'Libravatar Junio C Hamano3-22/+9
Various fixes in code paths that move untracked files away to make room. * en/removing-untracked-fixes: Documentation: call out commands that nuke untracked files/directories Comment important codepaths regarding nuking untracked files/dirs unpack-trees: avoid nuking untracked dir in way of locally deleted file unpack-trees: avoid nuking untracked dir in way of unmerged file Change unpack_trees' 'reset' flag into an enum Remove ignored files by default when they are in the way unpack-trees: make dir an internal-only struct unpack-trees: introduce preserve_ignored to unpack_trees_options read-tree, merge-recursive: overwrite ignored files by default checkout, read-tree: fix leak of unpack_trees_options.dir t2500: add various tests for nuking untracked files
2021-10-13Merge branch 'ds/add-rm-with-sparse-index'Libravatar Junio C Hamano2-1/+14
"git add", "git mv", and "git rm" have been adjusted to avoid updating paths outside of the sparse-checkout definition unless the user specifies a "--sparse" option. * ds/add-rm-with-sparse-index: advice: update message to suggest '--sparse' mv: refuse to move sparse paths rm: skip sparse paths with missing SKIP_WORKTREE rm: add --sparse option add: update --renormalize to skip sparse paths add: update --chmod to skip sparse paths add: implement the --sparse option add: skip tracked paths outside sparse-checkout cone add: fail when adding an untracked sparse file dir: fix pattern matching on dirs dir: select directories correctly t1092: behavior for adding sparse files t3705: test that 'sparse_entry' is unstaged
2021-10-12Sync with Git 2.33.1Libravatar Junio C Hamano2-75/+138
2021-10-12Git 2.33.1Libravatar Junio C Hamano1-0/+138
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12Merge branch 'cb/cvsserver' into maintLibravatar Junio C Hamano1-14/+13
"git cvsserver" had a long-standing bug in its authentication code, which has finally been corrected (it is unclear and is a separate question if anybody is seriously using it, though). * cb/cvsserver: Documentation: cleanup git-cvsserver git-cvsserver: protect against NULL in crypt(3) git-cvsserver: use crypt correctly to compare password hashes
2021-10-12Merge branch 'en/am-abort-fix' into maintLibravatar Junio C Hamano1-0/+2
When "git am --abort" fails to abort correctly, it still exited with exit status of 0, which has been corrected. * en/am-abort-fix: am: fix incorrect exit status on am fail to abort t4151: add a few am --abort tests git-am.txt: clarify --abort behavior
2021-10-12Merge branch 'jk/log-warn-on-bogus-encoding' into maintLibravatar Junio C Hamano2-3/+5
Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails
2021-10-12Merge branch 'ka/want-ref-in-namespace' into maintLibravatar Junio C Hamano1-5/+9
"git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper
2021-10-12Merge branch 'sg/column-nl' into maintLibravatar Junio C Hamano1-1/+1
The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option
2021-10-12Merge branch 'rs/branch-allow-deleting-dangling' into maintLibravatar Junio C Hamano1-1/+2
"git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force
2021-10-12Merge branch 'en/pull-conflicting-options' into maintLibravatar Junio C Hamano3-9/+54
"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options
2021-10-12Merge branch 'po/git-config-doc-mentions-help-c' into maintLibravatar Junio C Hamano1-0/+3
Doc update. * po/git-config-doc-mentions-help-c: doc: config, tell readers of `git help --config`
2021-10-12Merge branch 'ma/doc-git-version' into maintLibravatar Junio C Hamano2-0/+32
Doc update. * ma/doc-git-version: documentation: add documentation for 'git version'
2021-10-12Merge branch 'bs/doc-bugreport-outdir' into maintLibravatar Junio C Hamano1-2/+2
Docfix. * bs/doc-bugreport-outdir: Documentation: fix default directory of git bugreport -o
2021-10-12Merge branch 'es/walken-tutorial-fix' into maintLibravatar Junio C Hamano1-2/+2
Typofix. * es/walken-tutorial-fix: doc: fix syntax error and the format of printf
2021-10-12Merge branch 'en/merge-strategy-docs' into maintLibravatar Junio C Hamano4-40/+53
Documentation updates. * en/merge-strategy-docs: Update error message and code comment merge-strategies.txt: add coverage of the `ort` merge strategy git-rebase.txt: correct out-of-date and misleading text about renames merge-strategies.txt: fix simple capitalization error merge-strategies.txt: avoid giving special preference to patience algorithm merge-strategies.txt: do not imply using copy detection is desired merge-strategies.txt: update wording for the resolve strategy Documentation: edit awkward references to `git merge-recursive` directory-rename-detection.txt: small updates due to merge-ort optimizations git-rebase.txt: correct antiquated claims about --rebase-merges
2021-10-12Merge branch 'ab/bundle-doc' into maintLibravatar Junio C Hamano1-30/+117
Doc update. * ab/bundle-doc: bundle doc: replace "basis" with "prerequsite(s)" bundle doc: elaborate on rev<->ref restriction bundle doc: elaborate on object prerequisites bundle doc: rewrite the "DESCRIPTION" section
2021-10-11Twelfth batchLibravatar Junio C Hamano1-0/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-11Merge branch 'jk/ref-paranoia'Libravatar Junio C Hamano1-9/+10
The ref iteration code used to optionally allow dangling refs to be shown, which has been tightened up. * jk/ref-paranoia: refs: drop "broken" flag from for_each_fullref_in() ref-filter: drop broken-ref code entirely ref-filter: stop setting FILTER_REFS_INCLUDE_BROKEN repack, prune: drop GIT_REF_PARANOIA settings refs: turn on GIT_REF_PARANOIA by default refs: omit dangling symrefs when using GIT_REF_PARANOIA refs: add DO_FOR_EACH_OMIT_DANGLING_SYMREFS flag refs-internal.h: reorganize DO_FOR_EACH_* flag documentation refs-internal.h: move DO_FOR_EACH_* flags next to each other t5312: be more assertive about command failure t5312: test non-destructive repack t5312: create bogus ref as necessary t5312: drop "verbose" helper t5600: provide detached HEAD for corruption failures t5516: don't use HEAD ref for invalid ref-deletion tests t7900: clean up some more broken refs
2021-10-11Merge branch 'tb/midx-write-propagate-namehash'Libravatar Junio C Hamano1-0/+4
"git multi-pack-index write --bitmap" learns to propagate the hashcache from original bitmap to resulting bitmap. * tb/midx-write-propagate-namehash: t5326: test propagating hashcache values p5326: generate pack bitmaps before writing the MIDX bitmap p5326: don't set core.multiPackIndex unnecessarily p5326: create missing 'perf-tag' tag midx.c: respect 'pack.writeBitmapHashcache' when writing bitmaps pack-bitmap.c: propagate namehash values from existing bitmaps t/helper/test-bitmap.c: add 'dump-hashes' mode
2021-10-06The eleventh batchLibravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-06Merge branch 'os/status-docfix'Libravatar Junio C Hamano1-1/+1
Docfix. * os/status-docfix: doc: fix capitalization in "git status --porcelain=v2" description
2021-10-06Merge branch 'ws/refer-to-forkpoint-config-in-rebase-doc'Libravatar Junio C Hamano1-1/+2
Doc update. * ws/refer-to-forkpoint-config-in-rebase-doc: Document `rebase.forkpoint` in rebase man page
2021-10-06Merge branch 'gc/doc-first-contribution-reroll'Libravatar Junio C Hamano1-11/+31
Doc update. * gc/doc-first-contribution-reroll: MyFirstContribution: Document --range-diff option when writing v2
2021-10-06Merge branch 'ew/midx-doc-update'Libravatar Junio C Hamano1-1/+3
Doc tweak. * ew/midx-doc-update: doc/technical: update note about core.multiPackIndex
2021-10-06Merge branch 'tb/commit-graph-usage-fix'Libravatar Junio C Hamano1-3/+3
Regression in "git commit-graph" command line parsing has been corrected. * tb/commit-graph-usage-fix: builtin/multi-pack-index.c: disable top-level --[no-]progress builtin/commit-graph.c: don't accept common --[no-]progress
2021-10-04Documentation/git-status: mention how to detect copiesLibravatar Johannes Altmanninger1-1/+1
The man page documents that git-status can find copies, but does not mention how. Whereas git-diff has command line options -C, there is no such option for git-status - it will only detect copies when the "status.renames" config option is "copies" or "copy". Document that in git-status.txt because this has confused me and others[1]. [1]: https://www.reddit.com/r/git/comments/ppc2l9/how_to_get_a_file_with_copied_status/ Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-04Documentation/git-status: document porcelain status T (typechange)Libravatar Johannes Altmanninger1-7/+10
As reported in [1], T is missing from the description of porcelain status letters in git-status(1) (whereas T *is* documented in git-diff-files(1) and friends). Document T right after M (modified) because the two are very similar. [1] https://github.com/fish-shell/fish-shell/issues/8311 Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-04Documentation/diff-format: state in which cases porcelain status is TLibravatar Johannes Altmanninger1-1/+1
Porcelain status letter T is documented as "type of the file", which is technically correct but not enough information for users that are not so familiar with this term from systems programming. In particular, given that the only supported file types are "regular file", "symbolic link" and "submodule", the term "file type" is surely opaque to the many(?) users who are not aware that symbolic links can be tracked - I thought that a "chmod +x" could cause the T status (wrong, it's M). Explicitly document the three file types so users know if/how they want to handle this. Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-04Documentation/git-status: remove impossible porcelain status DR and DCLibravatar Johannes Altmanninger1-2/+2
Commit 176ea74793 ("wt-status.c: handle worktree renames", 2017-12-27) made a porcelain status like .R or .C possible. They occur only when the source file is added to the index and the destination file is added with --intent-to-add. They also documented DR, but that status is impossible. The index change D means that the source file does not exist in the index. The worktree change R/C states that the file has been renamed/copied since the index, but that's impossible if it did not exist there. Reported-by: Elijah Newren <newren@gmail.com> Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-03The tenth batchLibravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-03Merge branch 'cb/cvsserver'Libravatar Junio C Hamano1-14/+13
"git cvsserver" had a long-standing bug in its authentication code, which has finally been corrected (it is unclear and is a separate question if anybody is seriously using it, though). * cb/cvsserver: Documentation: cleanup git-cvsserver git-cvsserver: protect against NULL in crypt(3) git-cvsserver: use crypt correctly to compare password hashes
2021-09-28doc: fix capitalization in "git status --porcelain=v2" descriptionLibravatar Orgad Shaneh1-1/+1
The summary line had xy, while the description (and other sub-sections) has XY. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-28The ninth batchLibravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-28Merge branch 'jk/reduce-malloc-in-v2-servers'Libravatar Junio C Hamano1-1/+5
Code cleanup to limit memory consumption and tighten protocol message parsing. * jk/reduce-malloc-in-v2-servers: ls-refs: reject unknown arguments serve: reject commands used as capabilities serve: reject bogus v2 "command=ls-refs=foo" docs/protocol-v2: clarify some ls-refs ref-prefix details ls-refs: ignore very long ref-prefix counts serve: drop "keys" strvec serve: provide "receive" function for session-id capability serve: provide "receive" function for object-format capability serve: add "receive" method for v2 capabilities table serve: return capability "value" from get_capability() serve: rename is_command() to parse_command()
2021-09-28rm: add --sparse optionLibravatar Derrick Stolee1-0/+6
As we did previously in 'git add', add a '--sparse' option to 'git rm' that allows modifying paths outside of the sparse-checkout definition. The existing checks in 'git rm' are restricted to tracked files that have the SKIP_WORKTREE bit in the current index. Future changes will cause 'git rm' to reject removing paths outside of the sparse-checkout definition, even if they are untracked or do not have the SKIP_WORKTREE bit. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-28add: implement the --sparse optionLibravatar Derrick Stolee1-1/+8
We previously modified 'git add' to refuse updating index entries outside of the sparse-checkout cone. This is justified to prevent users from accidentally getting into a confusing state when Git removes those files from the working tree at some later point. Unfortunately, this caused some workflows that were previously possible to become impossible, especially around merge conflicts outside of the sparse-checkout cone. These were documented in tests within t1092. We now re-enable these workflows using a new '--sparse' option to 'git add'. This allows users to signal "Yes, I do know what I'm doing with these files," and accept the consequences of the files leaving the worktree later. We delay updating the advice message until implementing a similar option in 'git rm' and 'git mv'. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27Documentation: call out commands that nuke untracked files/directoriesLibravatar Elijah Newren3-5/+8
Some commands have traditionally also removed untracked files (or directories) that were in the way of a tracked file we needed. Document these cases. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27read-tree, merge-recursive: overwrite ignored files by defaultLibravatar Elijah Newren1-17/+1
This fixes a long-standing patchwork of ignored files handling in read-tree and merge-recursive, called out and suggested by Junio long ago. Quoting from commit dcf0c16ef1 ("core.excludesfile clean-up" 2007-11-16): git-read-tree takes --exclude-per-directory=<gitignore>, not because the flexibility was needed. Again, this was because the option predates the standardization of the ignore files. ... On the other hand, I think it makes perfect sense to fix git-read-tree, git-merge-recursive and git-clean to follow the same rule as other commands. I do not think of a valid use case to give an exclude-per-directory that is nonstandard to read-tree command, outside a "negative" test in the t1004 test script. This patch is the first step to untangle this mess. The next step would be to teach read-tree, merge-recursive and clean (in C) to use setup_standard_excludes(). History shows each of these were partially or fully fixed: * clean was taught the new trick in 1617adc7a0 ("Teach git clean to use setup_standard_excludes()", 2007-11-14). * read-tree was primarily used by checkout & merge scripts. checkout and merge later became builtins and were both fixed to use the new setup_standard_excludes() handling in fc001b526c ("checkout,merge: loosen overwriting untracked file check based on info/exclude", 2011-11-27). So the primary users were fixed, though read-tree itself was not. * merge-recursive has now been replaced as the default merge backend by merge-ort. merge-ort fixed this by using setup_standard_excludes() starting early in its implementation; see commit 6681ce5cf6 ("merge-ort: add implementation of checkout()", 2020-12-13), largely due to its design depending on checkout() and thus being influenced by the checkout code. However, merge-recursive itself was not fixed here, in part because its design meant it had difficulty differentiating between untracked files, ignored files, leftover tracked files that haven't been removed yet due to order of processing files, and files written by itself due to collisions). Make the conversion more complete by now handling read-tree and handling at least the unpack_trees() portion of merge-recursive. While merge-recursive is on its way out, fixing the unpack_trees() portion is easy and facilitates some of the later changes in this series. Note that fixing read-tree makes the --exclude-per-directory option to read-tree useless, so we remove it from the documentation (though we continue to accept it if passed). The read-tree changes happen to fix a bug in t1013. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27refs: turn on GIT_REF_PARANOIA by defaultLibravatar Jeff King1-9/+10
The original point of the GIT_REF_PARANOIA flag was to include broken refs in iterations, so that possibly-destructive operations would not silently ignore them (and would generally instead try to operate on the oids and fail when the objects could not be accessed). We already turned this on by default for some dangerous operations, like "repack -ad" (where missing a reachability tip would mean dropping the associated history). But it was not on for general use, even though it could easily result in the spreading of corruption (e.g., imagine cloning a repository which simply omits some of its refs because their objects are missing; the result quietly succeeds even though you did not clone everything!). This patch turns on GIT_REF_PARANOIA by default. So a clone as mentioned above would actually fail (upload-pack tells us about the broken ref, and when we ask for the objects, pack-objects fails to deliver them). This may be inconvenient when working with a corrupted repository, but: - we are better off to err on the side of complaining about corruption, and then provide mechanisms for explicitly loosening safety. - this is only one type of corruption anyway. If we are missing any other objects in the history that _aren't_ ref tips, then we'd behave similarly (happily show the ref, but then barf when we started traversing). We retain the GIT_REF_PARANOIA variable, but simply default it to "1" instead of "0". That gives the user an escape hatch for loosening this when working with a corrupt repository. It won't work across a remote connection to upload-pack (because we can't necessarily set environment variables on the remote), but there the client has other options (e.g., choosing which refs to fetch). As a bonus, this also makes ref iteration faster in general (because we don't have to call has_object_file() for each ref), though probably not noticeably so in the general case. In a repo with a million refs, it shaved a few hundred milliseconds off of upload-pack's advertisement; that's noticeable, but most repos are not nearly that large. The possible downside here is that any operation which iterates refs but doesn't ever open their objects may now quietly claim to have X when the object is corrupted (e.g., "git rev-list new-branch --not --all" will treat a broken ref as uninteresting). But again, that's not really any different than corruption below the ref level. We might have refs/heads/old-branch as non-corrupt, but we are not actively checking that we have the entire reachable history. Or the pointed-to object could even be corrupted on-disk (but our "do we have it" check would still succeed). In that sense, this is merely bringing ref-corruption in line with general object corruption. One alternative implementation would be to actually check for broken refs, and then _immediately die_ if we see any. That would cause the "rev-list --not --all" case above to abort immediately. But in many ways that's the worst of all worlds: - it still spends time looking up the objects an extra time - it still doesn't catch corruption below the ref level - it's even more inconvenient; with the current implementation of GIT_REF_PARANOIA for something like upload-pack, we can make the advertisement and let the client choose a non-broken piece of history. If we bail as soon as we see a broken ref, they cannot even see the advertisement. The test changes here show some of the fallout. A non-destructive "git repack -adk" now fails by default (but we can override it). Deleting a broken ref now actually tells the hooks the correct "before" state, rather than a confusing null oid. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-24doc/technical: update note about core.multiPackIndexLibravatar Eric Wong1-1/+3
MIDX files are used by default since commit 18e449f86b74 (midx: enable core.multiPackIndex by default, 2020-09-25) Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23The eighth batchLibravatar Junio C Hamano1-0/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Merge branch 'ma/doc-git-version'Libravatar Junio C Hamano2-0/+32
Doc update. * ma/doc-git-version: documentation: add documentation for 'git version'
2021-09-23Merge branch 'ab/retire-option-argument'Libravatar Junio C Hamano1-5/+0
An oddball OPTION_ARGUMENT feature has been removed from the parse-options API. * ab/retire-option-argument: parse-options API: remove OPTION_ARGUMENT feature difftool: use run_command() API in run_file_diff() difftool: prepare "diff" cmdline in cmd_difftool() difftool: prepare "struct child_process" in cmd_difftool()
2021-09-23Merge branch 'po/git-config-doc-mentions-help-c'Libravatar Junio C Hamano1-0/+3
Doc update. * po/git-config-doc-mentions-help-c: doc: config, tell readers of `git help --config`