summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2020-03-25Git 2.26.1Libravatar Junio C Hamano10-0/+61
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-18RelNotes/2.26.0: fix various typosLibravatar Elijah Newren1-4/+4
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.25.3Libravatar Junio C Hamano9-0/+56
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Sync with Git 2.25.2Libravatar Junio C Hamano2-24/+61
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.25.2Libravatar Junio C Hamano1-0/+60
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Merge branch 'jk/doc-credential-helper' into maintLibravatar Junio C Hamano1-1/+88
Docfix. * jk/doc-credential-helper: doc: move credential helper info into gitcredentials(7)
2020-03-17Merge branch 'jc/doc-single-h-is-for-help' into maintLibravatar Junio C Hamano2-1/+8
Both "git ls-remote -h" and "git grep -h" give short usage help, like any other Git subcommand, but it is not unreasonable to expect that the former would behave the same as "git ls-remote --head" (there is no other sensible behaviour for the latter). The documentation has been updated in an attempt to clarify this. * jc/doc-single-h-is-for-help: Documentation: clarify that `-h` alone stands for `help`
2020-03-17Merge branch 'en/check-ignore' into maintLibravatar Junio C Hamano1-3/+9
"git check-ignore" did not work when the given path is explicitly marked as not ignored with a negative entry in the .gitignore file. * en/check-ignore: check-ignore: fix documentation and implementation to match
2020-03-17Merge branch 'jk/push-option-doc-markup-fix' into maintLibravatar Junio C Hamano1-2/+2
Doc markup fix. * jk/push-option-doc-markup-fix: doc/config/push: use longer "--" line for preformatted example
2020-03-17Merge branch 'jk/doc-diff-parallel' into maintLibravatar Junio C Hamano1-1/+1
Update to doc-diff. * jk/doc-diff-parallel: doc-diff: use single-colon rule in rendering Makefile
2020-03-17Git 2.24.2Libravatar Junio C Hamano8-0/+51
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.23.2Libravatar Junio C Hamano7-0/+46
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.22.3Libravatar Junio C Hamano6-0/+41
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.21.2Libravatar Junio C Hamano5-0/+36
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.20.3Libravatar Junio C Hamano4-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.19.4Libravatar Junio C Hamano3-0/+26
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.18.3Libravatar Junio C Hamano2-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.17.4Libravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16Git 2.26-rc2Libravatar Junio C Hamano1-4/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-12Hopefully the final batch before -rc2Libravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-12Merge branch 'en/rebase-backend'Libravatar Junio C Hamano1-0/+10
Band-aid fixes for two fallouts from switching the default "rebase" backend. * en/rebase-backend: git-rebase.txt: highlight backend differences with commit rewording sequencer: clear state upon dropping a become-empty commit i18n: unmark a message in rebase.c
2020-03-11git-rebase.txt: highlight backend differences with commit rewordingLibravatar Elijah Newren1-0/+10
As noted by Junio: Back when "git am" was written, it was not considered a bug that the "git am --resolved" option did not offer the user a chance to update the log message to match the adjustment of the code the user made, but honestly, I'd have to say that it is a bug in "git am" in that over time it wasn't adjusted to the new world order where we encourage users to describe what they did when the automation hiccuped by opening an editor. These days, even when automation worked well (e.g. a clean auto-merge with "git merge"), we open an editor. The world has changed, and so should the expectations. Junio also suggested providing a workaround such as allowing --no-edit together with git rebase --continue, but that should probably be done in a patch after the git-2.26.0 release. For now, just document the known difference in the Behavioral Differences section. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-11Merge branch 'jc/doc-single-h-is-for-help'Libravatar Junio C Hamano2-1/+8
Both "git ls-remote -h" and "git grep -h" give short usage help, like any other Git subcommand, but it is not unreasonable to expect that the former would behave the same as "git ls-remote --head" (there is no other sensible behaviour for the latter). The documentation has been updated in an attempt to clarify this. * jc/doc-single-h-is-for-help: Documentation: clarify that `-h` alone stands for `help`
2020-03-09Git 2.26-rc1Libravatar Junio C Hamano1-0/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-09Merge branch 'pb/am-show-current-patch'Libravatar Junio C Hamano1-4/+6
"git am --short-current-patch" is a way to show the piece of e-mail for the stopped step, which is not suitable to directly feed "git apply" (it is designed to be a good "git am" input). It learned a new option to show only the patch part. * pb/am-show-current-patch: am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch am: support --show-current-patch=raw as a synonym for--show-current-patch am: convert "resume" variable to a struct parse-options: convert "command mode" to a flag parse-options: add testcases for OPT_CMDMODE()
2020-03-09Merge branch 'am/pathspec-f-f-more'Libravatar Junio C Hamano2-71/+134
"git rm" and "git stash" learns the new "--pathspec-from-file" option. * am/pathspec-f-f-more: stash push: support the --pathspec-from-file option stash: eliminate crude option parsing doc: stash: synchronize <pathspec> description doc: stash: document more options doc: stash: split options from description (2) doc: stash: split options from description (1) rm: support the --pathspec-from-file option doc: rm: synchronize <pathspec> description
2020-03-05Git 2.26-rc0Libravatar Junio C Hamano1-0/+40
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05Merge branch 'es/recursive-single-branch-clone'Libravatar Junio C Hamano1-1/+5
"git clone --recurse-submodules --single-branch" now uses the same single-branch option when cloning the submodules. * es/recursive-single-branch-clone: clone: pass --single-branch during --recurse-submodules submodule--helper: use C99 named initializer
2020-03-05Merge branch 'bc/wildcard-credential'Libravatar Junio C Hamano1-1/+3
A configuration element used for credential subsystem can now use wildcard pattern to specify for which set of URLs the entry applies. * bc/wildcard-credential: credential: allow wildcard patterns when matching config credential: use the last matching username in the config t0300: add tests for some additional cases t1300: add test for urlmatch with multiple wildcards mailmap: add an additional email address for brian m. carlson
2020-03-05Merge branch 'ds/sparse-add'Libravatar Junio C Hamano1-0/+7
"git sparse-checkout" learned a new "add" subcommand. * ds/sparse-add: sparse-checkout: allow one-character directories in cone mode sparse-checkout: work with Windows paths sparse-checkout: create 'add' subcommand sparse-checkout: extract pattern update from 'set' subcommand sparse-checkout: extract add_patterns_from_input()
2020-03-02The eighth batch for 2.26Libravatar Junio C Hamano1-0/+37
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-02Merge branch 'en/rebase-backend'Libravatar Junio C Hamano2-22/+154
"git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am"). The rebase.backend configuration variable can be set to customize. * en/rebase-backend: rebase: rename the two primary rebase backends rebase: change the default backend from "am" to "merge" rebase: make the backend configurable via config setting rebase tests: repeat some tests using the merge backend instead of am rebase tests: mark tests specific to the am-backend with --am rebase: drop '-i' from the reflog for interactive-based rebases git-prompt: change the prompt for interactive-based rebases rebase: add an --am option rebase: move incompatibility checks between backend options a bit earlier git-rebase.txt: add more details about behavioral differences of backends rebase: allow more types of rebases to fast-forward t3432: make these tests work with either am or merge backends rebase: fix handling of restrict_revision rebase: make sure to pass along the quiet flag to the sequencer rebase, sequencer: remove the broken GIT_QUIET handling t3406: simplify an already simple test rebase (interactive-backend): fix handling of commits that become empty rebase (interactive-backend): make --keep-empty the default t3404: directly test the behavior of interest git-rebase.txt: update description of --allow-empty-message
2020-03-02Merge branch 'en/check-ignore'Libravatar Junio C Hamano1-3/+9
"git check-ignore" did not work when the given path is explicitly marked as not ignored with a negative entry in the .gitignore file. * en/check-ignore: check-ignore: fix documentation and implementation to match
2020-03-02Merge branch 'jk/push-option-doc-markup-fix'Libravatar Junio C Hamano1-2/+2
Doc markup fix. * jk/push-option-doc-markup-fix: doc/config/push: use longer "--" line for preformatted example
2020-03-02Merge branch 'jk/doc-diff-parallel'Libravatar Junio C Hamano1-1/+1
Update to doc-diff. * jk/doc-diff-parallel: doc-diff: use single-colon rule in rendering Makefile
2020-02-27Documentation: clarify that `-h` alone stands for `help`Libravatar Junio C Hamano2-1/+8
We seem to be getting new users who get confused every 20 months or so with this "-h consistently wants to give help, but the commands to which `-h` may feel like a good short-form option want it to mean something else." compromise. Let's make sure that the readers know that `git cmd -h` (with no other arguments) is a way to get usage text, even for commands like ls-remote and grep. Also extend the description that is already in gitcli.txt, as it is clear that users still get confused with the current text. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-25The seventh batch for 2.26Libravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-25Merge branch 'es/doc-mentoring'Libravatar Junio C Hamano1-0/+36
Doc for new contributors. * es/doc-mentoring: MyFirstContribution: rephrase contact info MyFirstContribution: add avenues for getting help
2020-02-25Merge branch 'es/bright-colors'Libravatar Junio C Hamano1-1/+3
The basic 7 colors learned the brighter counterparts (e.g. "brightred"). * es/bright-colors: color.c: alias RGB colors 8-15 to aixterm colors color.c: support bright aixterm colors color.c: refactor color_output arguments
2020-02-25Merge branch 'bw/remote-rename-update-config'Libravatar Junio C Hamano2-6/+8
"git remote rename X Y" needs to adjust configuration variables (e.g. branch.<name>.remote) whose value used to be X to Y. branch.<name>.pushRemote is now also updated. * bw/remote-rename-update-config: remote rename/remove: gently handle remote.pushDefault config config: provide access to the current line number remote rename/remove: handle branch.<name>.pushRemote config values remote: clean-up config callback remote: clean-up by returning early to avoid one indentation pull --rebase/remote rename: document and honor single-letter abbreviations rebase types
2020-02-25clone: pass --single-branch during --recurse-submodulesLibravatar Emily Shaffer1-1/+5
Previously, performing "git clone --recurse-submodules --single-branch" resulted in submodules cloning all branches even though the superproject cloned only one branch. Pipe --single-branch through the submodule helper framework to make it to 'clone' later on. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=diff to retrieve .git/rebase-apply/patchLibravatar Paolo Bonzini1-5/+6
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output of "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. Add a new mode to "git am --show-current-patch" in order to straighten the suggestion. Reported-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=raw as a synonym for--show-current-patchLibravatar Paolo Bonzini1-4/+5
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. To simplify worktree operations and to avoid that users poke into .git, it would be better if "git am" also provided a mode that copies .git/rebase-merge/patch to stdout. One possibility could be to have completely separate options, introducing for example --show-current-message (for .git/rebase-apply/NNNN) and --show-current-diff (for .git/rebase-apply/patch), while possibly deprecating --show-current-patch. That would even remove the need for the first two patches in the series. However, the long common prefix would have prevented using an abbreviated option such as "--show". Therefore, I chose instead to add a string argument to --show-current-patch. The new argument is optional, so that "git am --show-current-patch"'s behavior remains backwards-compatible. The next choice to make is how to handle multiple --show-current-patch options. Right now, something like "git am --abort --show-current-patch" is rejected, and the previous suggestion would likewise have naturally rejected a command line like git am --show-current-message --show-current-diff Therefore, I decided to also reject for example git am --show-current-patch=diff --show-current-patch=raw In other words the whole of --show-current-patch=xxx (including the optional argument) is treated as the command mode. I found this to be more consistent and intuitive, even though it differs from the usual "last one wins" semantics of the git command line. Add the code to parse submodes based on the above design, where for now "raw" is the only valid submode. "raw" prints the full e-mail message just like "git am --show-current-patch". Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20credential: allow wildcard patterns when matching configLibravatar brian m. carlson1-1/+3
In some cases, a user will want to use a specific credential helper for a wildcard pattern, such as https://*.corp.example.com. We have code that handles this already with the urlmatch code, so let's use that instead of our custom code. Since the urlmatch code is a superset of our current matching in terms of capabilities, there shouldn't be any cases of things that matched previously that don't match now. However, in addition to wildcard matching, we now use partial path matching, which can cause slightly different behavior in the case that a helper applies to the prefix (considering path components) of the remote URL. While different, this is probably the behavior people were wanting anyway. Since we're using the urlmatch code, we need to encode the components we've gotten into a URL to match, so add a function to percent-encode data and format the URL with it. We now also no longer need to the custom code to match URLs, so let's remove it. Additionally, the urlmatch code always looks for the best match, whereas we want all matches for credential helpers to preserve existing behavior. Let's add an optional field, select_fn, that lets us control which items we want (in this case, all of them) and default it to the best-match code that already exists for other users. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19stash push: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy1-1/+19
Decisions taken for simplicity: 1) For now, `--pathspec-from-file` is declared incompatible with `--patch`, even when <file> is not `-`. Such use case is not really expected. 2) It is not allowed to pass pathspec in both args and file. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: synchronize <pathspec> descriptionLibravatar Alexandr Miloslavskiy1-2/+4
This patch continues the effort that is already applied to `git commit`, `git reset`, `git checkout` etc. 1) Added reference to 'linkgit:gitglossary[7]'. 2) Fixed mentions of incorrectly plural "pathspecs". Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: document more optionsLibravatar Alexandr Miloslavskiy1-0/+12
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: split options from description (2)Libravatar Alexandr Miloslavskiy1-35/+57
Together with the previous patch, this brings docs for `git stash` to the common layout used for most other commands (see for example docs for `git add`, `git commit`, `git checkout`, `git reset`) where all options are documented in a separate list. After some thinking and having a look at docs for `git svn` and `git `submodule`, I have arrived at following conclusions: * Options should be described in a list rather then text to facilitate lookup for user. * Single list is better then multiple lists because it avoids copy&pasting descriptions between subcommands (or, without copy&pasting, user will have to look up missing options in other subcommands). * As a consequence, commands section should only give brief info and list possible options. Since options have good enough names, user will only need to look up the "interesting" options. * Every option should list which subcommands support it. I have decided to use alphabetical sorting in the list of options to facilitate lookup for user. There is some text editing done to make old descriptions better fit into the list-style format. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: split options from description (1)Libravatar Alexandr Miloslavskiy1-33/+35
This patch moves blocks of text as-is to make it easier to review the next patch. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19rm: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy1-1/+16
Decisions taken for simplicity: 1) It is not allowed to pass pathspec in both args and file. Adjustments were needed for `if (!argc)` block: This code actually means "pathspec is not present". Previously, pathspec could only come from commandline arguments, so testing for `argc` was a valid way of testing for the presence of pathspec. But this is no longer true with `--pathspec-from-file`. During the entire `--pathspec-from-file` story, I tried to keep its behavior very close to giving pathspec on commandline, so that switching from one to another doesn't involve any surprises. However, throwing usage at user in the case of empty `--pathspec-from-file` would puzzle because there's nothing wrong with "usage" (that is, argc/argv array). On the other hand, throwing usage in the old case also feels bad to me. While it's less of a puzzle, I (as user) never liked the experience of comparing my commandline to "usage", trying to spot a difference. Since it's already known what the error is, it feels a lot better to give that specific error to user. Judging from [1] it doesn't seem that showing usage in this case was important (the patch was to avoid segfault), and it doesn't fit into how other commands react to empty pathspec (see for example `git add` with a custom message). Therefore, I decided to show new error text in both cases. In order to continue testing for error early, I moved `parse_pathspec()` higher. Now it happens before `read_cache()` / `hold_locked_index()` / `setup_work_tree()`, which shouldn't cause any issues. [1] Commit 7612a1ef ("git-rm: honor -n flag" 2006-06-09) Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>