summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
17 hoursEighth batchHEADmasterJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 daysSeventh batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 daysMerge branch 'jk/rev-parse-end-of-options'Junio C Hamano
"git rev-parse" learned the "--end-of-options" to help scripts to safely take a parameter that is supposed to be a revision, e.g. "git rev-parse --verify -q --end-of-options $rev". * jk/rev-parse-end-of-options: rev-parse: handle --end-of-options rev-parse: put all options under the "-" check rev-parse: don't accept options after dashdash
5 daysMerge branch 'jc/format-patch-name-max'Junio C Hamano
The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * jc/format-patch-name-max: format-patch: make output filename configurable
8 daysSixth batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8 daysMerge branch 'pb/blame-funcname-range-userdiff'Junio C Hamano
"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'
8 daysMerge branch 'ds/maintenance-part-3'Junio C Hamano
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 batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-11Merge branch 'mc/typofix'Junio C Hamano
Docfix. * mc/typofix: doc: fixing two trivial typos in Documentation/
2020-11-11Merge branch 'jc/abbrev-doc'Junio C Hamano
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'Junio C Hamano
Docfix. * so/format-patch-doc-on-default-diff-format: doc/diff-options: fix out of place mentions of '--patch/-p'
2020-11-10rev-parse: handle --end-of-optionsJeff King
We taught rev-list a new way to separate options from revisions in 19e8789b23 (revision: allow --end-of-options to end option parsing, 2019-08-06), but rev-parse uses its own parser. It should know about --end-of-options not only for consistency, but because it may be presented with similarly ambiguous cases. E.g., if a caller does: git rev-parse "$rev" -- "$path" to parse an untrusted input, then it will get confused if $rev contains an option-like string like "--local-env-vars". Or even "--not-real", which we'd keep as an option to pass along to rev-list. Or even more importantly: git rev-parse --verify "$rev" can be confused by options, even though its purpose is safely parsing untrusted input. On the plus side, it will always fail the --verify part, as it will not have parsed a revision, so the caller will generally "fail closed" rather than continue to use the untrusted string. But it will still trigger whatever option was in "$rev"; this should be mostly harmless, since rev-parse options are all read-only, but I didn't carefully audit all paths. This patch lets callers write: git rev-parse --end-of-options "$rev" -- "$path" and: git rev-parse --verify --end-of-options "$rev" which will both treat "$rev" always as a revision parameter. The latter is a bit clunky. It would be nicer if we had defined "--verify" to require that its next argument be the revision. But we have not historically done so, and: git rev-parse --verify -q "$rev" does currently work. I added a test here to confirm that we didn't break that. A few implementation notes: - We don't document --end-of-options explicitly in commands, but rather in gitcli(7). So I didn't give it its own section in git-rev-parse(1). But I did call it out specifically in the --verify section, and include it in the examples, which should show best practices. - We don't have to re-indent the main option-parsing block, because we can combine our "did we see end of options" check with "does it start with a dash". The exception is the pre-setup options, which need their own block. - We do however have to pull the "--" parsing out of the "does it start with dash" block, because we want to parse it even if we've seen --end-of-options. - We'll leave "--end-of-options" in the output. This is probably not technically necessary, as a careful caller will do: git rev-parse --end-of-options $revs -- $paths and anything in $revs will be resolved to an object id. However, it does help a slightly less careful caller like: git rev-parse --end-of-options $revs_or_paths where a path "--foo" will remain in the output as long as it also exists on disk. In that case, it's helpful to retain --end-of-options to get passed along to rev-list, s it would otherwise see just "--foo". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-10format-patch: make output filename configurableJunio C Hamano
For the past 15 years, we've used the hardcoded 64 as the length limit of the filename of the output from the "git format-patch" command. Since the value is shorter than the 80-column terminal, it could grow without line wrapping a bit. At the same time, since the value is longer than half of the 80-column terminal, we could fit two or more of them in "ls" output on such a terminal if we allowed to lower it. Introduce a new command line option --filename-max-length=<n> and a new configuration variable format.filenameMaxLength to override the hardcoded default. While we are at it, remove a check that the name of output directory does not exceed PATH_MAX---this check is pointless in that by the time control reaches the function, the caller would already have done an equivalent of "mkdir -p", so if the system does not like an overly long directory name, the control wouldn't have reached here, and otherwise, we know that the system allowed the output directory to exist. In the worst case, we will get an error when we try to open the output file and handle the error correctly anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Fourth batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Merge branch 'ab/git-remote-exit-code'Junio C Hamano
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'Junio C Hamano
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/Marlon Rac Cambasis
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 lengthJunio C Hamano
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 batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-02Merge branch 'jc/doc-final-resend'Junio C Hamano
Update developer doc. * jc/doc-final-resend: SubmittingPatches: clarify the purpose of the final resend
2020-11-02Merge branch 'es/tutorial-mention-asciidoc-early'Junio C Hamano
Doc update. * es/tutorial-mention-asciidoc-early: MyFirstContribution: clarify asciidoc dependency
2020-11-02Merge branch 've/userdiff-bash'Junio C Hamano
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'Junio C Hamano
"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'Junio C Hamano
"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'Junio C Hamano
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'Junio C Hamano
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 userdiffPhilippe Blain
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' descriptionPhilippe Blain
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 formattingPhilippe Blain
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'Philippe Blain
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'Sergey Organov
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 batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Sync with Git 2.29.2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Git 2.29.2v2.29.2maintJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29Merge branch 'cc/doc-filter-branch-typofix' into maintJunio C Hamano
Docfix. * cc/doc-filter-branch-typofix: filter-branch doc: fix filter-repo typo
2020-10-27First batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27Merge branch 'dl/checkout-guess'Junio C Hamano
"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'Junio C Hamano
"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'Junio C Hamano
"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'Junio C Hamano
"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'Junio C Hamano
"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'Junio C Hamano
"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/existingÆvar Arnfjörð Bjarmason
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-27SubmittingPatches: clarify the purpose of the final resendJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26other small fixes for 2.29.2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26Merge branch 'cc/doc-filter-branch-typofix'Junio C Hamano
Docfix. * cc/doc-filter-branch-typofix: filter-branch doc: fix filter-repo typo
2020-10-22Git 2.29.1v2.29.1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-22userdiff: support BashVictor Engmark
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 changesMichał Kępień
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 typoChristian Couder
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>