summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2020-11-18Sixth batchLibravatar Junio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18Merge branch 'pb/blame-funcname-range-userdiff'Libravatar Junio C Hamano7-53/+45
"git blame -L :funcname -- path" did not work well for a path for which a userdiff driver is defined. * pb/blame-funcname-range-userdiff: blame: simplify 'setup_blame_bloom_data' interface blame: simplify 'setup_scoreboard' interface blame: enable funcname blaming with userdiff driver line-log: mention both modes in 'blame' and 'log' short help doc: add more pointers to gitattributes(5) for userdiff blame-options.txt: also mention 'funcname' in '-L' description doc: line-range: improve formatting doc: log, gitk: move '-L' description to 'line-range-options.txt'
2020-11-18Merge branch 'ds/maintenance-part-3'Libravatar Junio C Hamano3-1/+182
Parts of "git maintenance" to ease writing crontab entries (and other scheduling system configuration) for it. * ds/maintenance-part-3: maintenance: add troubleshooting guide to docs maintenance: use 'incremental' strategy by default maintenance: create maintenance.strategy config maintenance: add start/stop subcommands maintenance: add [un]register subcommands for-each-repo: run subcommands on configured repos maintenance: add --schedule option and config maintenance: optionally skip --auto process
2020-11-11Fifth batchLibravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-11Merge branch 'mc/typofix'Libravatar Junio C Hamano3-3/+3
Docfix. * mc/typofix: doc: fixing two trivial typos in Documentation/
2020-11-11Merge branch 'jc/abbrev-doc'Libravatar Junio C Hamano6-11/+18
The documentation on the "--abbrev=<n>" option did not say the output may be longer than "<n>" hexdigits, which has been clarified. * jc/abbrev-doc: doc: clarify that --abbrev=<n> is about the minimum length
2020-11-11Merge branch 'so/format-patch-doc-on-default-diff-format'Libravatar Junio C Hamano1-3/+6
Docfix. * so/format-patch-doc-on-default-diff-format: doc/diff-options: fix out of place mentions of '--patch/-p'
2020-11-09Fourth batchLibravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Merge branch 'ab/git-remote-exit-code'Libravatar Junio C Hamano1-0/+11
Exit codes from "git remote add" etc. were not usable by scripted callers. * ab/git-remote-exit-code: remote: add meaningful exit code on missing/existing
2020-11-09Merge branch 'en/dir-rename-tests'Libravatar Junio C Hamano1-7/+8
More preliminary tests have been added to document desired outcome of various "directory rename" situations. * en/dir-rename-tests: t6423: more involved rules for renaming directories into each other t6423: update directory rename detection tests with new rule t6423: more involved directory rename test directory-rename-detection.txt: update references to regression tests
2020-11-05doc: fixing two trivial typos in Documentation/Libravatar Marlon Rac Cambasis3-3/+3
Fix misspelled "specified" and "occurred" in documentation and comments. Signed-off-by: Marlon Rac Cambasis <marlonrc08@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-04doc: clarify that --abbrev=<n> is about the minimum lengthLibravatar Junio C Hamano6-11/+18
Early text written in 2006 explains the "--abbrev=<n>" option to "show only a partial prefix", without saying that the length of the partial prefix is not necessarily the number given to the option to ensure that the output names the object uniquely. Update documentation for the diff family of commands, "blame", "branch --verbose", "ls-files" and "ls-tree" to stress that the short prefix must uniquely refer to an object, and <n> is merely the mininum number of hexdigits used in the prefix. Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-02Third batchLibravatar Junio C Hamano1-0/+80
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-02Merge branch 'jc/doc-final-resend'Libravatar Junio C Hamano1-3/+5
Update developer doc. * jc/doc-final-resend: SubmittingPatches: clarify the purpose of the final resend
2020-11-02Merge branch 'es/tutorial-mention-asciidoc-early'Libravatar Junio C Hamano1-2/+3
Doc update. * es/tutorial-mention-asciidoc-early: MyFirstContribution: clarify asciidoc dependency
2020-11-02Merge branch 've/userdiff-bash'Libravatar Junio C Hamano1-0/+3
The userdiff pattern learned to identify the function definition in POSIX shells and bash. * ve/userdiff-bash: userdiff: support Bash
2020-11-02Merge branch 'mk/diff-ignore-regex'Libravatar Junio C Hamano1-0/+5
"git diff" family of commands learned the "-I<regex>" option to ignore hunks whose changed lines all match the given pattern. * mk/diff-ignore-regex: diff: add -I<regex> that ignores matching changes merge-base, xdiff: zero out xpparam_t structures
2020-11-02Merge branch 'dl/diff-merge-base'Libravatar Junio C Hamano3-17/+35
"git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing. * dl/diff-merge-base: contrib/completion: complete `git diff --merge-base` builtin/diff-tree: learn --merge-base builtin/diff-index: learn --merge-base t4068: add --merge-base tests diff-lib: define diff_get_merge_base() diff-lib: accept option flags in run_diff_index() contrib/completion: extract common diff/difftool options git-diff.txt: backtick quote command text git-diff-index.txt: make --cached description a proper sentence t4068: remove unnecessary >tmp
2020-11-02Merge branch 'bk/sob-dco'Libravatar Junio C Hamano14-46/+52
Document that the meaning of a Signed-off-by trailer can vary from project to project in the end-user documentation, and clarify what it means to this project. * bk/sob-dco: Documentation: stylistically normalize references to Signed-off-by: SubmittingPatches: clarify DCO is our --signoff rule Documentation: clarify and expand description of --signoff doc: preparatory clean-up of description on the sign-off option
2020-11-02Merge branch 'ds/commit-graph-merging-fix'Libravatar Junio C Hamano1-1/+3
When "git commit-graph" detects the same commit recorded more than once while it is merging the layers, it used to die. The code now ignores all but one of them and continues. * ds/commit-graph-merging-fix: commit-graph: don't write commit-graph when disabled commit-graph: ignore duplicates when merging layers
2020-11-01doc: add more pointers to gitattributes(5) for userdiffLibravatar Philippe Blain3-4/+11
Several Git commands can make use of the builtin userdiff patterns, but it's not obvious in the documentation. Add pointers to the 'Defining a custom hunk header' part of gitattributes(5) in the description of the following options: - the '--function-context' option of `git diff` and friends - the '--function-context' option of `git grep` - the '-L :<funcname>' option of `git log`, `gitk` and `git blame` In 'git-grep.txt', take the opportunity to use backticks in the description of '--show-function', and improve the wording of the desription of '--function-context'. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-01blame-options.txt: also mention 'funcname' in '-L' descriptionLibravatar Philippe Blain2-4/+5
Make it clearer that a function can be blamed by feeding `git blame` '-L :<funcname>' by mentioning it at the beginnning of the description of the '-L' option. Also, in 'line-range-options.txt', which is used for git-log(1) and gitk(1), do not parenthesize the mention of the ':<funcname>' mode, to place it on equal footing with the '<start>,<end>' mode. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-01doc: line-range: improve formattingLibravatar Philippe Blain3-17/+17
Improve the formatting of the description of the line-range option '-L' for `git log`, `gitk` and `git blame`: - Use bold for <start>, <end> and <funcname> - Use backticks for literals Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-01doc: log, gitk: move '-L' description to 'line-range-options.txt'Libravatar Philippe Blain3-33/+17
The description of the '-L' option for `git log` and `gitk` is almost the same, but is repeated in both 'git-log.txt' and 'gitk.txt' (the difference being that 'git-log.txt' lists the option with a space after '-L', while 'gitk.txt' lists it as stuck and notes that `gitk` only understands the stuck form). Reduce duplication by creating a new file, 'line-range-options.txt', and include it in both files. To simplify the presentation, only list the stuck form for both commands, and remove the note about `gitk` only understanding the stuck form. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-31doc/diff-options: fix out of place mentions of '--patch/-p'Libravatar Sergey Organov1-3/+6
First, references to --patch and -p appeared in the description of git-format-patch, where the options themselves are not included. Next, the description of --unified option elsewhere had duplicate implied statements: "Implies --patch. Implies -p." Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-30Second batchLibravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Sync with Git 2.29.2Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Git 2.29.2Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Merge branch 'cc/doc-filter-branch-typofix' into maintLibravatar Junio C Hamano1-1/+1
Docfix. * cc/doc-filter-branch-typofix: filter-branch doc: fix filter-repo typo
2020-10-27First batchLibravatar Junio C Hamano1-0/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27Merge branch 'dl/checkout-guess'Libravatar Junio C Hamano3-9/+20
"git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * dl/checkout-guess: checkout: learn to respect checkout.guess Documentation/config/checkout: replace sq with backticks
2020-10-27Merge branch 'dl/checkout-p-merge-base'Libravatar Junio C Hamano2-0/+8
"git checkout -p A...B [-- <path>]" did not work, even though the same command without "-p" correctly used the merge-base between commits A and B. * dl/checkout-p-merge-base: t2016: add a NEEDSWORK about the PERL prerequisite add-patch: add NEEDSWORK about comparing commits Doc: document "A...B" form for <tree-ish> in checkout and switch builtin/checkout: fix `git checkout -p HEAD...` bug
2020-10-27Merge branch 'sb/clone-origin'Libravatar Junio C Hamano3-2/+9
"git clone" learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from. * sb/clone-origin: clone: allow configurable default for `-o`/`--origin` clone: read new remote name from remote_name instead of option_origin clone: validate --origin option before use refs: consolidate remote name validation remote: add tests for add and rename with invalid names clone: use more conventional config/option layering clone: add tests for --template and some disallowed option pairs
2020-10-27Merge branch 'sk/force-if-includes'Libravatar Junio C Hamano3-4/+37
"git push --force-with-lease[=<ref>]" can easily be misused to lose commits unless the user takes good care of their own "git fetch". A new option "--force-if-includes" attempts to ensure that what is being force-pushed was created after examining the commit at the tip of the remote ref that is about to be force-replaced. * sk/force-if-includes: t, doc: update tests, reference for "--force-if-includes" push: parse and set flag for "--force-if-includes" push: add reflog check for "--force-if-includes"
2020-10-27Merge branch 'ds/maintenance-part-2'Libravatar Junio C Hamano3-2/+68
"git maintenance", an extended big brother of "git gc", continues to evolve. * ds/maintenance-part-2: maintenance: add incremental-repack auto condition maintenance: auto-size incremental-repack batch maintenance: add incremental-repack task midx: use start_delayed_progress() midx: enable core.multiPackIndex by default maintenance: create auto condition for loose-objects maintenance: add loose-objects task maintenance: add prefetch task
2020-10-27Merge branch 'rs/worktree-list-show-locked'Libravatar Junio C Hamano1-2/+3
"git worktree list" now shows if each worktree is locked. This possibly may open us to show other kinds of states in the future. * rs/worktree-list-show-locked: worktree: teach `list` to annotate locked worktree
2020-10-27remote: add meaningful exit code on missing/existingLibravatar Ævar Arnfjörð Bjarmason1-0/+11
Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26SubmittingPatches: clarify the purpose of the final resendLibravatar Junio C Hamano1-3/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26other small fixes for 2.29.2Libravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26Merge branch 'cc/doc-filter-branch-typofix'Libravatar Junio C Hamano1-1/+1
Docfix. * cc/doc-filter-branch-typofix: filter-branch doc: fix filter-repo typo
2020-10-22Git 2.29.1Libravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-22userdiff: support BashLibravatar Victor Engmark1-0/+3
Support POSIX, bashism and mixed function declarations, all four compound command types, trailing comments and mixed whitespace. Even though Bash allows locale-dependent characters in function names <https://unix.stackexchange.com/a/245336/3645>, only detect function names with characters allowed by POSIX.1-2017 <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_235> for simplicity. This should cover the vast majority of use cases, and produces system-agnostic results. Since a word pattern has to be specified, but there is no easy way to know the default word pattern, use the default `IFS` characters for a starter. A later patch can improve this. Signed-off-by: Victor Engmark <victor@engmark.name> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20diff: add -I<regex> that ignores matching changesLibravatar Michał Kępień1-0/+5
Add a new diff option that enables ignoring changes whose all lines (changed, removed, and added) match a given regular expression. This is similar to the -I/--ignore-matching-lines option in standalone diff utilities and can be used e.g. to ignore changes which only affect code comments or to look for unrelated changes in commits containing a large number of automatically applied modifications (e.g. a tree-wide string replacement). The difference between -G/-S and the new -I option is that the latter filters output on a per-change basis. Use the 'ignore' field of xdchange_t for marking a change as ignored or not. Since the same field is used by --ignore-blank-lines, identical hunk emitting rules apply for --ignore-blank-lines and -I. These two options can also be used together in the same git invocation (they are complementary to each other). Rename xdl_mark_ignorable() to xdl_mark_ignorable_lines(), to indicate that it is logically a "sibling" of xdl_mark_ignorable_regex() rather than its "parent". Signed-off-by: Michał Kępień <michal@isc.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20filter-branch doc: fix filter-repo typoLibravatar Christian Couder1-1/+1
The name of the tool is 'git-filter-repo' not 'git-repo-filter'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20Documentation: stylistically normalize references to Signed-off-by:Libravatar Bradley M. Kuhn12-18/+18
Ted reported an old typo in the git-commit.txt and merge-options.txt. Namely, the phrase "Signed-off-by line" was used without either a definite nor indefinite article. Upon examination, it seems that the documentation (including items in Documentation/, but also option help strings) have been quite inconsistent on usage when referring to `Signed-off-by`. First, very few places used a definite or indefinite article with the phrase "Signed-off-by line", but that was the initial typo that led to this investigation. So, normalize using either an indefinite or definite article consistently. The original phrasing, in Commit 3f971fc425b (Documentation updates, 2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add --signoff, --check, and long option-names. 2005-12-09) switched to using "Add `Signed-off-by:` line", but didn't normalize the former commit to match. Later commits seem to have cut and pasted from one or the other, which is likely how the usage became so inconsistent. Junio stated on the git mailing list in <xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off the colon. Thus, prefer `Signed-off-by` (with backticks) for the documentation files and Signed-off-by (without backticks) for option help strings. Additionally, Junio argued that "trailer" is now the standard term to refer to `Signed-off-by`, saying that "becomes plenty clear that we are not talking about any random line in the log message". As such, prefer "trailer" over "line" anywhere the former word fits. However, leave alone those few places in documentation that use Signed-off-by to refer to the process (rather than the specific trailer), or in places where mail headers are generally discussed in comparison with Signed-off-by. Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu> Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20SubmittingPatches: clarify DCO is our --signoff ruleLibravatar Junio C Hamano1-11/+14
The description on sign-off and DCO was written back in the days where there was only a choice between "use sign-off and it means the contributor agrees to the Linux-kernel style DCO" and "not using sign-off at all will make your patch unusable". These days, we are trying to clarify that the exact meaning of a sign-off varies project to project. Let's be more explicit when presenting what _our_ rules are. It is of secondary importance that it originally came from the kernel project, so move the description as a historical note at the end, while cautioning that what a sign-off means to us may be different from what it means to other projects contributors may have been used to. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20Documentation: clarify and expand description of --signoffLibravatar Bradley M. Kuhn1-6/+10
Building on past documentation improvements in b2c150d3aa (Expand documentation describing --signoff, 2016-01-05), further clarify that any project using Git may and often does set its own policy. However, leave intact reference to the Linux DCO, which Git also uses. It is reasonable for Git to advocate for its own Signed-off-by methodology in its documentation, as long as the documentation remains respectful that YMMV and other projects may well have very different contributor representations tied to Signed-off-by. Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20doc: preparatory clean-up of description on the sign-off optionLibravatar Junio C Hamano3-18/+17
Almost identical text on the signed-off-by trailer appears in the documentation for "git commit" and "git merge" and its friends. Introduce a new signoff-option.txt file to be shared. A couple of things of note are: - The short-form "-s" is available only in "git commit", but not in commands that are friends of "git merge", as it is used as a short-hand for "--strategy". - The original lacks description on the negated "--no-signoff" form on "git commit" side, but it equally is applicable. It however was unclear in the original text that not adding a Signed-off-by trailer is the default, so rephrase to explain it as a way to countermand a --signoff option that appeared earlier on the same command line. This is in preparation to apply a further clarification on what exactly the Signed-off-by trailer means. Suggested-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-16MyFirstContribution: clarify asciidoc dependencyLibravatar Emily Shaffer1-2/+3
Per IRC: [19:52] <lkmandy> With respect to the MyFirstContribution tutorial, I will like to suggest this - Under the section "Adding Documentation", just before the "make all doc" command, it will be really helpful to prompt a user to check if they have the asciidoc package installed, if they don't, the command should be provided or they can just be pointed to install it So, let's move the note about the dependency to before the build command blockquote. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-16t6423: more involved rules for renaming directories into each otherLibravatar Elijah Newren1-0/+3
Testcases 12b and 12c were both slightly weird; they were marked as having a weird resolution, but with the note that even straightforward simple rules can give weird results when the input is bizarre. However, during optimization work for merge-ort, I discovered a significant speedup that is possible if we add one more fairly straightforward rule: we don't bother doing directory rename detection if there are no new files added to the directory on the other side of the history to be affected by the directory rename. This seems like an obvious and straightforward rule, but there was one funny corner case where directory rename detection could affect only existing files: the funny corner case where two directories are renamed into each other on opposite sides of history. In other words, it only results in a different output for testcases 12b and 12c. Since we already thought testcases 12b and 12c were weird anyway, and because the optimization often has a significant effect on common cases (but is entirely prevented if we can't change how 12b and 12c function), let's add the additional rule and tweak how 12b and 12c work. Split both testcases into two (one where we add no new files, and one where the side that doesn't rename a given directory will add files to it), and mark them with the new expectation. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>