summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2021-10-18The fourteenth batchLibravatar Junio C Hamano1-0/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'tz/doc-link-to-bundle-format-fix'Libravatar Junio C Hamano1-0/+1
Doc update. * tz/doc-link-to-bundle-format-fix: doc: add bundle-format to TECH_DOCS
2021-10-18Merge branch 'bs/doc-blame-color-lines'Libravatar Junio C Hamano3-17/+44
The "--color-lines" and "--color-by-age" options of "git blame" have been missing, which are now documented. * bs/doc-blame-color-lines: blame: document --color-* options blame: describe default output format
2021-10-18Merge branch 'jk/cat-file-batch-all-wo-replace'Libravatar Junio C Hamano1-2/+4
"git cat-file --batch" with the "--batch-all-objects" option is supposed to iterate over all the objects found in a repository, but it used to translate these object names using the replace mechanism, which defeats the point of enumerating all objects in the repository. This has been corrected. * jk/cat-file-batch-all-wo-replace: cat-file: use packed_object_info() for --batch-all-objects cat-file: split ordered/unordered batch-all-objects callbacks cat-file: disable refs/replace with --batch-all-objects cat-file: mention --unordered along with --batch-all-objects t1006: clean up broken objects
2021-10-18Merge branch 'tb/repack-write-midx'Libravatar Junio C Hamano2-4/+33
"git repack" has been taught to generate multi-pack reachability bitmaps. * tb/repack-write-midx: test-read-midx: fix leak of bitmap_index struct builtin/repack.c: pass `--refs-snapshot` when writing bitmaps builtin/repack.c: make largest pack preferred builtin/repack.c: support writing a MIDX while repacking builtin/repack.c: extract showing progress to a variable builtin/repack.c: rename variables that deal with non-kept packs builtin/repack.c: keep track of existing packs unconditionally midx: preliminary support for `--refs-snapshot` builtin/multi-pack-index.c: support `--stdin-packs` mode midx: expose `write_midx_file_only()` publicly
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano5-65/+1
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-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-13doc: add bundle-format to TECH_DOCSLibravatar Todd Zullinger1-0/+1
A link to the bundle-format was added in 5c8273d57c (bundle doc: rewrite the "DESCRIPTION" section, 2021-07-31). Ensure `technical/bundle-format.html` is created to avoid a broken link in `git-bundle.html`. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-08cat-file: disable refs/replace with --batch-all-objectsLibravatar Jeff King1-1/+2
When we're enumerating all objects in the object database, it doesn't make sense to respect refs/replace. The point of this option is to enumerate all of the objects in the database at a low level. By definition we'd already show the replacement object's contents (under its real oid), and showing those contents under another oid is almost certainly working against what the user is trying to do. Note that you could make the same argument for something like: git show-index <foo.idx | awk '{print $2}' | git cat-file --batch but there we can't know in cat-file exactly what the user intended, because we don't know the source of the input. They could be trying to do low-level debugging, or they could be doing something more high-level (e.g., imagine a porcelain built around cat-file for its object accesses). So in those cases, we'll have to rely on the user specifying "git --no-replace-objects" to tell us what to do. One _could_ make an argument that "cat-file --batch" is sufficiently low-level plumbing that it should not respect replace-objects at all (and the caller should do any replacement if they want it). But we have been doing so for some time. The history is a little tangled: - looking back as far as v1.6.6, we would not respect replace refs for --batch-check, but would for --batch (because the former used sha1_object_info(), and the replace mechanism only affected actual object reads) - this discrepancy was made even weirder by 98e2092b50 (cat-file: teach --batch to stream blob objects, 2013-07-10), where we always output the header using the --batch-check code, and then printed the object separately. This could lead to "cat-file --batch" dying (when it notices the size or type changed for a non-blob object) or even producing bogus output (in streaming mode, we didn't notice that we wrote the wrong number of bytes). - that persisted until 1f7117ef7a (sha1_file: perform object replacement in sha1_object_info_extended(), 2013-12-11), which then respected replace refs for both forms. So it has worked reliably this way for over 7 years, and we should make sure it continues to do so. That could also be an argument that --batch-all-objects should not change behavior (which this patch is doing), but I really consider the current behavior to be an unintended bug. It's a side effect of how the code is implemented (feeding the oids back into oid_object_info() rather than looking at what we found while reading the loose and packed object storage). The implementation is straight-forward: we just disable the global read_replace_refs flag when we're in --batch-all-objects mode. It would perhaps be a little cleaner to change the flag we pass to oid_object_info_extended(), but that's not enough. We also read objects via read_object_file() and stream_blob_to_fd(). The former could switch to its _extended() form, but the streaming code has no mechanism for disabling replace refs. Setting the global flag works, and as a bonus, it's impossible to have any "oops, we're sometimes replacing the object and sometimes not" bugs in the output (like the ones caused by 98e2092b50 above). The tests here cover the regular-input and --batch-all-objects cases, for both --batch-check and --batch. There is a test in t6050 that covers the regular-input case with --batch already, but this new one goes much further in actually verifying the output (plus covering --batch-check explicitly). This is perhaps a little overkill and the tests would be simpler just covering --batch-check, but I wanted to make sure we're checking that --batch output is consistent between the header and the content. The global-flag technique used here makes that easy to get right, but this is future-proofing us against regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08cat-file: mention --unordered along with --batch-all-objectsLibravatar Jeff King1-2/+3
The note on ordering for --batch-all-objects was written when that was the only possible ordering. These days we have --unordered, too, so let's point to it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08blame: document --color-* optionsLibravatar Bagas Sanjaya3-17/+31
Commit cdc2d5f11f1a (builtin/blame: dim uninteresting metadata lines, 2018-04-23) and 25d5f52901f0 (builtin/blame: highlight recently changed lines, 2018-04-23) introduce --color-lines and --color-by-age options to git blame, respectively. While both options are mentioned in usage help, they aren't documented in git-blame(1). Document them. Co-authored-by: Dr. Matthias St. Pierre <m.st.pierre@ncp-e.com> Signed-off-by: Dr. Matthias St. Pierre <m.st.pierre@ncp-e.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-10-01blame: describe default output formatLibravatar Bagas Sanjaya1-0/+13
While there is descriptions for porcelain and incremental output formats, the default format isn't described. Describe that format for the sake of completeness. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-28builtin/repack.c: make largest pack preferredLibravatar Taylor Blau1-0/+4
When repacking into a geometric series and writing a multi-pack bitmap, it is beneficial to have the largest resulting pack be the preferred object source in the bitmap's MIDX, since selecting the large packs can lead to fewer broken delta chains and better compression. Teach 'git repack' to identify this pack and pass it to the MIDX write machinery in order to mark it as preferred. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-28builtin/repack.c: support writing a MIDX while repackingLibravatar Taylor Blau1-4/+10
Teach `git repack` a new `--write-midx` option for callers that wish to persist a multi-pack index in their repository while repacking. There are two existing alternatives to this new flag, but they don't cover our particular use-case. These alternatives are: - Call 'git multi-pack-index write' after running 'git repack', or - Set 'GIT_TEST_MULTI_PACK_INDEX=1' in your environment when running 'git repack'. The former works, but introduces a gap in bitmap coverage between repacking and writing a new MIDX (since the repack may have deleted a pack included in the existing MIDX, invalidating it altogether). Setting the 'GIT_TEST_' environment variable is obviously unsupported. In fact, even if it were supported officially, it still wouldn't work, because it generates the MIDX *after* redundant packs have been dropped, leading to the same issue as above. Introduce a new option which eliminates this race by teaching `git repack` to generate the MIDX at the critical point: after the new packs have been written and moved into place, but before the redundant packs have been removed. This option is compatible with `git repack`'s '--bitmap' option (it changes the interpretation to be: "write a bitmap corresponding to the MIDX after one has been generated"). There is a little bit of additional noise in the patch below to avoid repeating ourselves when selecting which packs to delete. Instead of a single loop as before (where we iterate over 'existing_packs', decide if a pack is worth deleting, and if so, delete it), we have two loops (the first where we decide which ones are worth deleting, and the second where we actually do the deleting). This makes it so we have a single check we can make consistently when (1) telling the MIDX which packs we want to exclude, and (2) actually unlinking the redundant packs. There is also a tiny change to short-circuit the body of write_midx_included_packs() when no packs remain in the case of an empty repository. The MIDX code does not handle this, so avoid trying to generate a MIDX covering zero packs in the first place. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>