summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2020-03-26The second batch post 2.26 cycleLibravatar Junio C Hamano1-0/+53
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-26Merge branch 'tg/retire-scripted-stash'Libravatar Junio C Hamano1-13/+5
"git stash" has kept an escape hatch to use the scripted version for a few releases, which got stale. It has been removed. * tg/retire-scripted-stash: stash: remove the stash.useBuiltin setting stash: get git_stash_config at the top level
2020-03-26Merge branch 'bc/sha-256-part-1-of-4'Libravatar Junio C Hamano3-1/+32
SHA-256 transition continues. * bc/sha-256-part-1-of-4: (22 commits) fast-import: add options for rewriting submodules fast-import: add a generic function to iterate over marks fast-import: make find_marks work on any mark set fast-import: add helper function for inserting mark object entries fast-import: permit reading multiple marks files commit: use expected signature header for SHA-256 worktree: allow repository version 1 init-db: move writing repo version into a function builtin/init-db: add environment variable for new repo hash builtin/init-db: allow specifying hash algorithm on command line setup: allow check_repository_format to read repository format t/helper: make repository tests hash independent t/helper: initialize repository if necessary t/helper/test-dump-split-index: initialize git repository t6300: make hash algorithm independent t6300: abstract away SHA-1-specific constants t: use hash-specific lookup tables to define test constants repository: require a build flag to use SHA-256 hex: add functions to parse hex object IDs in any algorithm hex: introduce parsing variants taking hash algorithms ...
2020-03-25The first batch post 2.26 cycleLibravatar Junio C Hamano1-0/+41
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-25Merge branch 'jc/config-tar'Libravatar Junio C Hamano3-7/+8
Improve the structure of the documentation source a bit. * jc/config-tar: separate tar.* config to its own source file
2020-03-25Merge branch 'rs/doc-passthru-fetch-options'Libravatar Junio C Hamano1-3/+7
Doc update. * rs/doc-passthru-fetch-options: pull: document more passthru options
2020-03-25Merge branch 'jc/maintain-doc'Libravatar Junio C Hamano1-13/+39
Doc update. * jc/maintain-doc: update how-to-maintain-git
2020-03-25Merge branch 'js/https-proxy-config'Libravatar Junio C Hamano1-0/+21
A handful of options to configure SSL when talking to proxies have been added. * js/https-proxy-config: http: add environment variable support for HTTPS proxies http: add client cert support for HTTPS proxies
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-18separate tar.* config to its own source fileLibravatar Junio C Hamano3-7/+8
Even though there is only one configuration variable in the namespace, it is not quite right to have tar.umask described among the variables for tag.* namespace. 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-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-11pull: document more passthru optionsLibravatar René Scharfe1-3/+7
git pull accepts the options --dry-run, -p/--prune, --refmap, and -t/--tags since a32975f516 (pull: pass git-fetch's options to git-fetch, 2015-06-18), -j/--jobs since 62104ba14a (submodules: allow parallel fetching, add tests and documentation, 2015-12-15), and --set-upstream since 24bc1a1292 (pull, fetch: add --set-upstream option, 2019-08-19). Update its documentation to match. Signed-off-by: René Scharfe <l.s.r@web.de> 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-09update how-to-maintain-gitLibravatar Junio C Hamano1-13/+39
Some parts of the workflow described in the document has got a bit stale with the recent toolchain improvements. Update the procedure a bit, and also describe the convention used around SQUASH??? fixups. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05stash: remove the stash.useBuiltin settingLibravatar Thomas Gummerer1-13/+5
Remove the stash.useBuiltin setting which was added as an escape hatch to disable the builtin version of stash first released with Git 2.22. Carrying the legacy version is a maintenance burden, and has in fact become out of date failing a test since the 2.23 release, without anyone noticing until now. So users would be getting a hint to fall back to a potentially buggy version of the tool. We used to shell out to git config to get the useBuiltin configuration to avoid changing any global state before spawning legacy-stash. However that is no longer necessary, so just use the 'git_config' function to get the setting instead. Similar to what we've done in d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18), where we remove the corresponding setting for rebase, we leave the documentation in place, so people can refer back to it when searching for it online, and so we can refer to it in the commit message. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05http: add environment variable support for HTTPS proxiesLibravatar Jorge Lopez Silva1-4/+8
Add 4 environment variables that can be used to configure the proxy cert, proxy ssl key, the proxy cert password protected flag, and the CA info for the proxy. Documentation for the options was also updated. Signed-off-by: Jorge Lopez Silva <jalopezsilva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05http: add client cert support for HTTPS proxiesLibravatar Jorge Lopez Silva1-0/+17
Git supports performing connections to HTTPS proxies, but we don't support doing mutual authentication with them (through TLS). Add the necessary options to be able to send a client certificate to the HTTPS proxy. A client certificate can provide an alternative way of authentication instead of using 'ProxyAuthorization' or other more common methods of authentication. Libcurl supports this functionality already, so changes are somewhat minimal. The feature is guarded by the first available libcurl version that supports these options. 4 configuration options are added and documented, cert, key, cert password protected and CA info. The CA info should be used to specify a different CA path to validate the HTTPS proxy cert. Signed-off-by: Jorge Lopez Silva <jalopezsilva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-28fast-import: add options for rewriting submodulesLibravatar brian m. carlson1-0/+20
When converting a repository using submodules from one hash algorithm to another, it is necessary to rewrite the submodules from the old algorithm to the new algorithm, since only references to submodules, not their contents, are written to the fast-export stream. Without rewriting the submodules, fast-import fails with an "Invalid dataref" error when encountering a submodule in another algorithm. Add a pair of options, --rewrite-submodules-from and --rewrite-submodules-to, that take a list of marks produced by fast-export and fast-import, respectively, when processing the submodule. Use these marks to map the submodule commits from the old algorithm to the new algorithm. We read marks into two corresponding struct mark_set objects and then perform a mapping from the old to the new using a hash table. This lets us reuse the same mark parsing code that is used elsewhere and allows us to efficiently read and match marks based on their ID, since mark files need not be sorted. Note that because we're using a khash table for the object IDs, and this table copies values of struct object_id instead of taking references to them, it's necessary to zero the struct object_id values that we use to insert and look up in the table. Otherwise, we would end up with SHA-1 values that don't match because of whatever stack garbage might be left in the unused area. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-24builtin/init-db: add environment variable for new repo hashLibravatar brian m. carlson1-0/+6
For the foreseeable future, SHA-1 will be the default algorithm for Git. However, when running the testsuite, we want to be able to test an arbitrary algorithm. It would be quite burdensome and very untidy to have to specify the algorithm we'd like to test every time we initialized a new repository somewhere in the testsuite, so add an environment variable to allow us to specify the default hash algorithm for Git. This has the benefit that we can set it once for the entire testsuite and not have to think about it. In the future, users can also use it to set the default for their repositories if they would like to do so. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24builtin/init-db: allow specifying hash algorithm on command lineLibravatar brian m. carlson1-1/+6
Allow the user to specify the hash algorithm on the command line by using the --object-format option to git init. Validate that the user is not attempting to reinitialize a repository with a different hash algorithm. Ensure that if we are writing a non-SHA-1 repository that we set the repository version to 1 and write the objectFormat extension. Restrict this option to work only when ENABLE_SHA256 is set until the codebase is in a situation to fully support this. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.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>