summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
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-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-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>
2020-10-16t6423: update directory rename detection tests with new ruleLibravatar Elijah Newren1-4/+1
While investigating the issues highlighted by the testcase in the previous patch, I also found a shortcoming in the directory rename detection rules. Split testcase 6b into two to explain this issue and update directory-rename-detection.txt to remove one of the previous rules that I know believe to be detrimental. Also, update the wording around testcase 8e; while we are not modifying the results of that testcase, we were previously unsure of the appropriate resolution of that test and the new rule makes the previously chosen resolution for that testcase a bit more solid. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-16directory-rename-detection.txt: update references to regression testsLibravatar Elijah Newren1-3/+4
The regression tests for directory rename detection were renamed from t6043 to t6423 in commit 919df31955 ("Collect merge-related tests to t64xx", 2020-08-10); update this file to match. Also, add a small clarification to nearby text while we're at it. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-12worktree: teach `list` to annotate locked worktreeLibravatar Rafael Silva1-2/+3
The "git worktree list" shows the absolute path to the working tree, the commit that is checked out and the name of the branch. It is not immediately obvious which of the worktrees, if any, are locked. "git worktree remove" refuses to remove a locked worktree with an error message. If "git worktree list" told which worktrees are locked in its output, the user would not even attempt to remove such a worktree, or would realize that "git worktree remove -f -f <path>" is required. Teach "git worktree list" to append "locked" to its output. The output from the command becomes like so: $ git worktree list /path/to/main abc123 [master] /path/to/worktree 456def (detached HEAD) /path/to/locked-worktree 123abc (detached HEAD) locked Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Rafael Silva <rafaeloliveira.cs@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-09commit-graph: don't write commit-graph when disabledLibravatar Derrick Stolee1-1/+3
The core.commitGraph config setting can be set to 'false' to prevent parsing commits from the commit-graph file(s). This causes an issue when trying to write with "--split" which needs to distinguish between commits that are in the existing commit-graph layers and commits that are not. The existing mechanism uses parse_commit() and follows by checking if there is a 'graph_pos' that shows the commit was parsed from the commit-graph file. When core.commitGraph=false, we do not parse the commits from the commit-graph and 'graph_pos' indicates that no commits are in the existing file. The --split logic moves forward creating a new layer on top that holds all reachable commits, then possibly merges down into those layers, resulting in duplicate commits. The previous change makes that merging process more robust to such a situation in case it happens in the written commit-graph data. The easy answer here is to avoid writing a commit-graph if reading the commit-graph is disabled. Since the resulting commit-graph will would not be read by subsequent Git processes. This is more natural than forcing core.commitGraph to be true for the 'write' process. Reported-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Helped-by: Jeff King <peff@peff.net> Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Git 2.29-rc1Libravatar Junio C Hamano1-13/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: fix the bnf like style of some commandsLibravatar Jean-Noël Avila1-1/+1
In command line options, variables are entered between < and > Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: git-remote fix upsLibravatar Jean-Noël Avila1-10/+10
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: use linkgit macro where needed.Libravatar Jean-Noël Avila1-1/+1
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08git-bisect-lk2009: make continuation of list indentedLibravatar Jean-Noël Avila1-8/+8
That's clearer asciidoc formatting. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08checkout: learn to respect checkout.guessLibravatar Denton Liu3-1/+12
The current behavior of git checkout/switch is that --guess is currently enabled by default. However, some users may not wish for this to happen automatically. Instead of forcing users to specify --no-guess manually each time, teach these commands the checkout.guess configuration variable that gives users the option to set a default behavior. Teach the completion script to recognize the new config variable and disable DWIM logic if it is set to false. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07Doc: document "A...B" form for <tree-ish> in checkout and switchLibravatar Denton Liu2-0/+8
Using "A...B" has been supported for the <tree-ish> argument for a while. However, its support has never been explicitly documented. Explicitly document it so that users know that it is available. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07Documentation/config/checkout: replace sq with backticksLibravatar Denton Liu1-8/+8
The modern style for Git documentation is to use backticks to quote any command-line documenation so that it is typeset in monospace. Replace all single quotes with backticks to conform to this. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>