summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2019-09-30Fourth batchLibravatar Junio C Hamano1-2/+69
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-30Merge branch 'ds/commit-graph-on-fetch'Libravatar Junio C Hamano2-0/+18
A configuration variable tells "git fetch" to write the commit graph after finishing. * ds/commit-graph-on-fetch: fetch: add fetch.writeCommitGraph config setting
2019-09-30Merge branch 'ds/include-exclude'Libravatar Junio C Hamano3-5/+5
The internal code originally invented for ".gitignore" processing got reshuffled and renamed to make it less tied to "excluding" and stress more that it is about "matching", as it has been reused for things like sparse checkout specification that want to check if a path is "included". * ds/include-exclude: unpack-trees: rename 'is_excluded_from_list()' treewide: rename 'exclude' methods to 'pattern' treewide: rename 'EXCL_FLAG_' to 'PATTERN_FLAG_' treewide: rename 'struct exclude_list' to 'struct pattern_list' treewide: rename 'struct exclude' to 'struct path_pattern'
2019-09-30Merge branch 'dl/rebase-i-keep-base'Libravatar Junio C Hamano1-3/+27
"git rebase --keep-base <upstream>" tries to find the original base of the topic being rebased and rebase on top of that same base, which is useful when running the "git rebase -i" (and its limited variant "git rebase -x"). The command also has learned to fast-forward in more cases where it can instead of replaying to recreate identical commits. * dl/rebase-i-keep-base: rebase: teach rebase --keep-base rebase tests: test linear branch topology rebase: fast-forward --fork-point in more cases rebase: fast-forward --onto in more cases rebase: refactor can_fast_forward into goto tower t3432: test for --no-ff's interaction with fast-forward t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests t3432: test rebase fast-forward behavior t3431: add rebase --fork-point tests
2019-09-30Merge branch 'en/filter-branch-deprecation'Libravatar Junio C Hamano7-57/+272
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test
2019-09-30Merge branch 'en/merge-options-ff-and-friends'Libravatar Junio C Hamano1-12/+16
Doc update. * en/merge-options-ff-and-friends: merge-options.txt: clarify meaning of various ff-related options
2019-09-30Merge branch 'dt/remote-helper-doc-re-lock-option'Libravatar Junio C Hamano1-3/+7
Doc update. * dt/remote-helper-doc-re-lock-option: clarify documentation for remote helpers
2019-09-30Merge branch 'dl/format-patch-doc-test-cleanup'Libravatar Junio C Hamano2-10/+14
The documentation and tests for "git format-patch" have been cleaned up. * dl/format-patch-doc-test-cleanup: config/format.txt: specify default value of format.coverLetter Doc: add more detail for git-format-patch t4014: stop losing return codes of git commands t4014: remove confusing pipe in check_threading() t4014: use test_line_count() where possible t4014: let sed open its own files t4014: drop redirections to /dev/null t4014: use indentable here-docs t4014: remove spaces after redirect operators t4014: use sq for test case names t4014: move closing sq onto its own line t4014: s/expected/expect/ t4014: drop unnecessary blank lines from test cases
2019-09-18Third batchLibravatar Junio C Hamano1-0/+36
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18Merge branch 'md/list-objects-filter-combo'Libravatar Junio C Hamano1-0/+16
The list-objects-filter API (used to create a sparse/lazy clone) learned to take a combined filter specification. * md/list-objects-filter-combo: list-objects-filter-options: make parser void list-objects-filter-options: clean up use of ALLOC_GROW list-objects-filter-options: allow mult. --filter strbuf: give URL-encoding API a char predicate fn list-objects-filter-options: make filter_spec a string_list list-objects-filter-options: move error check up list-objects-filter: implement composite filters list-objects-filter-options: always supply *errbuf list-objects-filter: put omits set in filter struct list-objects-filter: encapsulate filter components
2019-09-18Merge branch 'cc/multi-promisor'Libravatar Junio C Hamano2-33/+92
Teach the lazy clone machinery that there can be more than one promisor remote and consult them in order when downloading missing objects on demand. * cc/multi-promisor: Move core_partial_clone_filter_default to promisor-remote.c Move repository_format_partial_clone to promisor-remote.c Remove fetch-object.{c,h} in favor of promisor-remote.{c,h} remote: add promisor and partial clone config to the doc partial-clone: add multiple remotes in the doc t0410: test fetching from many promisor remotes builtin/fetch: remove unique promisor remote limitation promisor-remote: parse remote.*.partialclonefilter Use promisor_remote_get_direct() and has_promisor_remote() promisor-remote: use repository_format_partial_clone promisor-remote: add promisor_remote_reinit() promisor-remote: implement promisor_remote_get_direct() Add initial support for many promisor remotes fetch-object: make functions return an error code t0410: remove pipes after git commands
2019-09-18Merge branch 'js/pre-merge-commit-hook'Libravatar Junio C Hamano3-1/+27
A new "pre-merge-commit" hook has been introduced. * js/pre-merge-commit-hook: merge: --no-verify to bypass pre-merge-commit hook git-merge: honor pre-merge-commit hook merge: do no-verify like commit t7503: verify proper hook execution
2019-09-18Merge branch 'js/rebase-r-strategy'Libravatar Junio C Hamano1-2/+0
"git rebase --rebase-merges" learned to drive different merge strategies and pass strategy specific options to them. * js/rebase-r-strategy: t3427: accelerate this test by using fast-export and fast-import rebase -r: do not (re-)generate root commits with `--root` *and* `--onto` t3418: test `rebase -r` with merge strategies t/lib-rebase: prepare for testing `git rebase --rebase-merges` rebase -r: support merge strategies other than `recursive` t3427: fix another incorrect assumption t3427: accommodate for the `rebase --merge` backend having been replaced t3427: fix erroneous assumption t3427: condense the unnecessarily repetitive test cases into three t3427: move the `filter-branch` invocation into the `setup` case t3427: simplify the `setup` test case significantly t3427: add a clarifying comment rebase: fold git-rebase--common into the -p backend sequencer: the `am` and `rebase--interactive` scripts are gone .gitignore: there is no longer a built-in `git-rebase--interactive` t3400: stop referring to the scripted rebase Drop unused git-rebase--am.sh
2019-09-09Second batchLibravatar Junio C Hamano1-1/+56
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-09Merge branch 'sb/userdiff-dts'Libravatar Junio C Hamano1-0/+2
Device-tree files learned their own userdiff patterns. * sb/userdiff-dts: userdiff: add a builtin pattern for dts files
2019-09-09Merge branch 'cb/fetch-set-upstream'Libravatar Junio C Hamano1-0/+7
"git fetch" learned "--set-upstream" option to help those who first clone from their private fork they intend to push to, add the true upstream via "git remote add" and then "git fetch" from it. * cb/fetch-set-upstream: pull, fetch: add --set-upstream option
2019-09-09Merge branch 'bm/repository-layout-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * bm/repository-layout-typofix: repository-layout.txt: correct pluralization of 'object'
2019-09-09Merge branch 'sg/diff-indent-heuristic-non-experimental'Libravatar Junio C Hamano1-1/+1
We promoted the "indent heuristics" that decides where to split diff hunks from experimental to the default a few years ago, but some stale documentation still marked it as experimental, which has been corrected. * sg/diff-indent-heuristic-non-experimental: diff: 'diff.indentHeuristic' is no longer experimental
2019-09-09Merge branch 'ds/feature-macros'Libravatar Junio C Hamano7-5/+41
A mechanism to affect the default setting for a (related) group of configuration variables is introduced. * ds/feature-macros: repo-settings: create feature.experimental setting repo-settings: create feature.manyFiles setting repo-settings: parse core.untrackedCache commit-graph: turn on commit-graph by default t6501: use 'git gc' in quiet mode repo-settings: consolidate some config settings
2019-09-09Merge branch 'jk/eoo'Libravatar Junio C Hamano1-0/+6
The command line parser learned "--end-of-options" notation; the standard convention for scripters to have hardcoded set of options first on the command line, and force the command to treat end-user input as non-options, has been to use "--" as the delimiter, but that would not work for commands that use "--" as a delimiter between revs and pathspec. * jk/eoo: gitcli: document --end-of-options parse-options: allow --end-of-options as a synonym for "--" revision: allow --end-of-options to end option parsing
2019-09-05treewide: rename 'exclude' methods to 'pattern'Libravatar Derrick Stolee3-5/+5
The first consumer of pattern-matching filenames was the .gitignore feature. In that context, storing a list of patterns as a 'struct exclude_list' makes sense. However, the sparse-checkout feature then adopted these structures and methods, but with the opposite meaning: these patterns match the files that should be included! It would be clearer to rename this entire library as a "pattern matching" library, and the callers apply exclusion/inclusion logic accordingly based on their needs. This commit renames several methods defined in dir.h to make more sense with the renamed 'struct exclude_list' to 'struct pattern_list' and 'struct exclude' to 'struct path_pattern': * last_exclude_matching() -> last_matching_pattern() * parse_exclude() -> parse_path_pattern() In addition, the word 'exclude' was replaced with 'pattern' in the methods below: * add_exclude_list() * add_excludes_from_file_to_list() * add_excludes_from_file() * add_excludes_from_blob_to_list() * add_exclude() * clear_exclude_list() A few methods with the word "exclude" remain. These will be handled seperately. In particular, the method "is_excluded()" is concretely about the .gitignore file relative to a specific directory. This is the important boundary between library and consumer: is_excluded() cares about .gitignore, but is_excluded() calls last_matching_pattern() to make that decision. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren7-57/+272
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05config/format.txt: specify default value of format.coverLetterLibravatar Denton Liu1-0/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05Doc: add more detail for git-format-patchLibravatar Denton Liu1-10/+13
In git-format-patch.txt, we were missing some key user information. First of all, document the special value of `--base=auto`. Next, while we're at it, surround option arguments with <> and change existing names such as "Message-Id" to "message id", which conforms with how existing documentation is written. Finally, document the `format.outputDirectory` config and change `format.coverletter` to use camel case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-03fetch: add fetch.writeCommitGraph config settingLibravatar Derrick Stolee2-0/+18
The commit-graph feature is now on by default, and is being written during 'git gc' by default. Typically, Git only writes a commit-graph when a 'git gc --auto' command passes the gc.auto setting to actualy do work. This means that a commit-graph will typically fall behind the commits that are being used every day. To stay updated with the latest commits, add a step to 'git fetch' to write a commit-graph after fetching new objects. The fetch.writeCommitGraph config setting enables writing a split commit-graph, so on average the cost of writing this file is very small. Occasionally, the commit-graph chain will collapse to a single level, and this could be slow for very large repos. For additional use, adjust the default to be true when feature.experimental is enabled. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-01merge-options.txt: clarify meaning of various ff-related optionsLibravatar Elijah Newren1-12/+16
As discovered on the mailing list, some of the descriptions of the ff-related options were unclear. Try to be more precise with what these options do. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-30clarify documentation for remote helpersLibravatar David Turner1-3/+7
Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27rebase: teach rebase --keep-baseLibravatar Denton Liu1-3/+27
A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series to the Git mailing list, one often starts on top of the current 'master'. While developing the patches, 'master' is also developed further and it is sometimes not the best idea to keep rebasing on top of 'master', but to keep the base commit as-is. In addition to this, a user wishing to test individual commits in a topic branch without changing anything may run git rebase -x ./test.sh master... master Since rebasing onto the merge base of the branch and the upstream is such a common case, introduce the --keep-base option as a shortcut. This allows us to rewrite the above as git rebase -i --keep-base master and git rebase -x ./test.sh --keep-base master respectively. Add tests to ensure --keep-base works correctly in the normal case and fails when there are multiple merge bases, both in regular and interactive mode. Also, test to make sure conflicting options cause rebase to fail. While we're adding test cases, add a missing set_fake_editor call to 'rebase -i --onto master...side'. While we're documenting the --keep-base option, change an instance of "merge-base" to "merge base", which is the consistent spelling. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22First batch after Git 2.23Libravatar Junio C Hamano1-0/+52
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22Merge branch 'en/fast-import-merge-doc'Libravatar Junio C Hamano1-1/+1
Doc update. * en/fast-import-merge-doc: git-fast-import.txt: clarify that multiple merge commits are allowed
2019-08-22Merge branch 'jk/tree-walk-overflow'Libravatar Junio C Hamano1-3/+5
Codepaths to walk tree objects have been audited for integer overflows and hardened. * jk/tree-walk-overflow: tree-walk: harden make_traverse_path() length computations tree-walk: add a strbuf wrapper for make_traverse_path() tree-walk: accept a raw length for traverse_path_len() tree-walk: use size_t consistently tree-walk: drop oid from traverse_info setup_traverse_info(): stop copying oid
2019-08-21userdiff: add a builtin pattern for dts filesLibravatar Stephen Boyd1-0/+2
The Linux kernel receives many patches to the devicetree files each release. The hunk header for those patches typically show nothing, making it difficult to figure out what node is being modified without applying the patch or opening the file and seeking to the context. Let's add a builtin 'dts' pattern to git so that users can get better diff output on dts files when they use the diff=dts driver. The regex has been constructed based on the spec at devicetree.org[1] and with some help from Johannes Sixt. [1] https://github.com/devicetree-org/devicetree-specification/releases/latest Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19repository-layout.txt: correct pluralization of 'object'Libravatar Ben Milman1-1/+1
In the description of 'objects/pack', 'object' should be pluralized to match the subject and agree with the rest of the sentence. Signed-off-by: Ben Milman <bpmilman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19pull, fetch: add --set-upstream optionLibravatar Corentin BOMPARD1-0/+7
Add the --set-upstream option to git pull/fetch which lets the user set the upstream configuration (branch.<current-branch-name>.merge and branch.<current-branch-name>.remote) for the current branch. A typical use-case is: git clone http://example.com/my-public-fork git remote add main http://example.com/project-main-repo git pull --set-upstream main master or, instead of the last line: git fetch --set-upstream main master git merge # or git rebase This is mostly equivalent to cloning project-main-repo (which sets upsteam) and then "git remote add" my-public-fork, but may feel more natural for people using a hosting system which allows forking from the web UI. This functionality is analog to "git push --set-upstream". Signed-off-by: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> Signed-off-by: Nathan BERBEZIER <nathan.berbezier@etu.univ-lyon1.fr> Signed-off-by: Pablo CHABANNE <pablo.chabanne@etu.univ-lyon1.fr> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Patch-edited-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-15diff: 'diff.indentHeuristic' is no longer experimentalLibravatar SZEDER Gábor1-1/+1
The indent heuristic started out as experimental, but it's now our default diff heuristic since 33de716387 (diff: enable indent heuristic by default, 2017-05-08). Alas, that commit didn't update the documentation, and the description of the 'diff.indentHeuristic' configuration variable still implies that it's experimental and not the default. Update the description of 'diff.indentHeuristic' to make it clear that it's the default diff heuristic. The description of the related '--indent-heuristic' option has already been updated in bab76141da (diff: --indent-heuristic is no longer experimental, 2017-10-29). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13repo-settings: create feature.experimental settingLibravatar Derrick Stolee3-2/+18
The 'feature.experimental' setting includes config options that are not committed to become defaults, but could use additional testing. Update the following config settings to take new defaults, and to use the repo_settings struct if not already using them: * 'pack.useSparse=true' * 'fetch.negotiationAlgorithm=skipping' In the case of fetch.negotiationAlgorithm, the existing logic would load the config option only when about to use the setting, so had a die() statement on an unknown string value. This is removed as now the config is parsed under prepare_repo_settings(). In general, this die() is probably misplaced and not valuable. A test was removed that checked this die() statement executed. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13repo-settings: create feature.manyFiles settingLibravatar Derrick Stolee4-1/+21
The feature.manyFiles setting is suitable for repos with many files in the working directory. By setting index.version=4 and core.untrackedCache=true, commands such as 'git status' should improve. While adding this setting, modify the index version precedence tests to check how this setting overrides the default for index.version is unset. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13commit-graph: turn on commit-graph by defaultLibravatar Derrick Stolee2-2/+2
The commit-graph feature has seen a lot of activity in the past year or so since it was introduced. The feature is a critical performance enhancement for medium- to large-sized repos, and does not significantly hurt small repos. Change the defaults for core.commitGraph and gc.writeCommitGraph to true so users benefit from this feature by default. There are several places in the test suite where the environment variable GIT_TEST_COMMIT_GRAPH is disabled to avoid reading a commit-graph, if it exists. The config option overrides the environment, so swap these. Some GIT_TEST_COMMIT_GRAPH assignments remain, and those are to avoid writing a commit-graph when a new commit is created. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-12git-fast-import.txt: clarify that multiple merge commits are allowedLibravatar Elijah Newren1-1/+1
The grammar for commits used a '?' rather than a '*' on the `merge` directive line, despite the fact that the code allows multiple `merge` directives in order to support n-way merges. In fact, elsewhere in git-fast-import.txt there is an explicit declaration that "an unlimited number of `merge` commands per commit are permitted by fast-import". Fix the grammar to match the intent and implementation. Reported-by: Joachim Klein <joachim.klein@automata.tools> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-11Sync with Git 2.22.1Libravatar Junio C Hamano1-0/+3
2019-08-11doc: fix repeated wordsLibravatar Mark Rushakoff9-9/+9
Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran "git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases where words were duplicated, e.g. "the the", and in most cases removed one of the repeated words. There were many false positives by this grep command, including deliberate repeated words like "really really" or valid uses of "that that" which I left alone, of course. I also did not correct any of the legitimate, accidentally repeated words in old RelNotes. Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-11Git 2.22.1Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-09Merge branch 'sg/fsck-config-in-doc' into maintLibravatar Junio C Hamano1-0/+5
Doc update. * sg/fsck-config-in-doc: Documentation/git-fsck.txt: include fsck.* config variables
2019-08-08Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-1/+1
Docfix. * nd/switch-and-restore: restore: fix typo in docs
2019-08-08Merge branch 'mr/doc-can-not-to-cannot'Libravatar Junio C Hamano6-7/+7
Docfix. * mr/doc-can-not-to-cannot: doc: typo: s/can not/cannot/ and s/is does/does/
2019-08-07merge: --no-verify to bypass pre-merge-commit hookLibravatar Michael J Gruber1-1/+2
Analogous to commit, introduce a '--no-verify' option which bypasses the pre-merge-commit hook. The shorthand '-n' is taken by '--no-stat' already. [js: * reworded commit message to reflect current state of --no-stat flag and new hook name * fixed flag documentation to reflect new hook name * cleaned up trailing whitespace * squashed test changes from the original series' patch 4/4 * modified tests to follow pattern from this series' patch 1/4 * added a test case for --no-verify with non-executable hook * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-07git-merge: honor pre-merge-commit hookLibravatar Michael J Gruber1-0/+21
git-merge does not honor the pre-commit hook when doing automatic merge commits, and for compatibility reasons this is going to stay. Introduce a pre-merge-commit hook which is called for an automatic merge commit just like pre-commit is called for a non-automatic merge commit (or any other commit). [js: * renamed hook from "pre-merge" to "pre-merge-commit" * only discard the index if the hook is actually present * expanded githooks documentation entry * clarified that hook should write messages to stderr * squashed test changes from the original series' patch 4/4 * modified tests to follow new pattern from this series' patch 1/4 * added a test case for non-executable merge hooks * added a test case for failed merges * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). * reworded commit message ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-07merge: do no-verify like commitLibravatar Michael J Gruber2-1/+5
f8b863598c ("builtin/merge: honor commit-msg hook for merges", 2017-09-07) introduced the no-verify flag to merge for bypassing the commit-msg hook, though in a different way from the implementation in commit.c. Change the implementation in merge.c to be the same as in commit.c so that both do the same in the same way. This also changes the output of "git merge --help" to be more clear that the hook return code is respected by default. [js: * reworded commit message * squashed documentation changes from original series' patch 3/4 ] Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-06gitcli: document --end-of-optionsLibravatar Jeff King1-0/+6
Now that --end-of-options is available for any users of setup_revisions() or parse_options(), which should be effectively everywhere, we can guide people to use it for all their disambiguating needs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05restore: fix typo in docsLibravatar William Chargin1-1/+1
Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>