summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12Merge branch 'jk/log-warn-on-bogus-encoding' into maintLibravatar Junio C Hamano2-3/+5
Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails
2021-10-12Merge branch 'ka/want-ref-in-namespace' into maintLibravatar Junio C Hamano1-5/+9
"git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper
2021-10-12Merge branch 'sg/column-nl' into maintLibravatar Junio C Hamano1-1/+1
The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option
2021-10-12Merge branch 'rs/branch-allow-deleting-dangling' into maintLibravatar Junio C Hamano1-1/+2
"git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force
2021-10-12Merge branch 'en/pull-conflicting-options' into maintLibravatar Junio C Hamano3-9/+54
"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options
2021-10-12Merge branch 'po/git-config-doc-mentions-help-c' into maintLibravatar Junio C Hamano1-0/+3
Doc update. * po/git-config-doc-mentions-help-c: doc: config, tell readers of `git help --config`
2021-10-12Merge branch 'ma/doc-git-version' into maintLibravatar Junio C Hamano2-0/+32
Doc update. * ma/doc-git-version: documentation: add documentation for 'git version'
2021-10-12Merge branch 'bs/doc-bugreport-outdir' into maintLibravatar Junio C Hamano1-2/+2
Docfix. * bs/doc-bugreport-outdir: Documentation: fix default directory of git bugreport -o
2021-10-12Merge branch 'es/walken-tutorial-fix' into maintLibravatar Junio C Hamano1-2/+2
Typofix. * es/walken-tutorial-fix: doc: fix syntax error and the format of printf
2021-10-12Merge branch 'en/merge-strategy-docs' into maintLibravatar Junio C Hamano4-40/+53
Documentation updates. * en/merge-strategy-docs: Update error message and code comment merge-strategies.txt: add coverage of the `ort` merge strategy git-rebase.txt: correct out-of-date and misleading text about renames merge-strategies.txt: fix simple capitalization error merge-strategies.txt: avoid giving special preference to patience algorithm merge-strategies.txt: do not imply using copy detection is desired merge-strategies.txt: update wording for the resolve strategy Documentation: edit awkward references to `git merge-recursive` directory-rename-detection.txt: small updates due to merge-ort optimizations git-rebase.txt: correct antiquated claims about --rebase-merges
2021-10-12Merge branch 'ab/bundle-doc' into maintLibravatar Junio C Hamano1-30/+117
Doc update. * ab/bundle-doc: bundle doc: replace "basis" with "prerequsite(s)" bundle doc: elaborate on rev<->ref restriction bundle doc: elaborate on object prerequisites bundle doc: rewrite the "DESCRIPTION" section
2021-09-14documentation: add documentation for 'git version'Libravatar Matthias Aßhauer2-0/+32
While 'git version' is probably the least complex git command, it is a non-experimental user-facing builtin command. As such it should have a help page. Both `git help` and `git version` can be called as options (`--help`/`--version`) that internally get converted to the corresponding command. Add a small paragraph to Documentation/git.txt describing how these two options interact with each other and link to this help page for the sub-options that `--version` can take. Well, currently there is only one sub-option, but that could potentially increase in future versions of Git. Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13doc: config, tell readers of `git help --config`Libravatar Philip Oakley1-0/+3
The `git help` command gained the ability to list config variables in 3ac68a93fd (help: add --config to list all available config, 2018-05-26) but failed to tell readers of the config documenation itself. Provide that cross reference. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07Documentation: fix default directory of git bugreport -oLibravatar Bagas Sanjaya1-2/+2
git bugreport writes bug report to the current directory by default, instead of repository root. Fix the documentation. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-01docs: clarify the interaction of transfer.hideRefs and namespacesLibravatar Kim Altintop1-5/+9
Expand the section about namespaces in the documentation of `transfer.hideRefs` to point out the subtle differences between `upload-pack` and `receive-pack`. ffcfb68176 (upload-pack.c: treat want-ref relative to namespace, 2021-07-30) taught `upload-pack` to reject `want-ref`s for hidden refs, which is now mentioned. It is clarified that at no point the name of a hidden ref is revealed, but the object id it points to may. Signed-off-by: Kim Altintop <kim@eagain.st> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-30doc: fix syntax error and the format of printfLibravatar Zoker1-2/+2
Fix syntax and correct the format of printf in MyFirstObjectWalk.txt Signed-off-by: Zoker <kaixuanguiqu@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27branch: allow deleting dangling branches with --forceLibravatar René Scharfe1-1/+2
git branch only allows deleting branches that point to valid commits. Skip that check if --force is given, as the caller is indicating with it that they know what they are doing and accept the consequences. This allows deleting dangling branches, which previously had to be reset to a valid start-point using --force first. Reported-by: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27docs: use "character encoding" to refer to commit-object encodingLibravatar Jeff King2-2/+2
The word "encoding" can mean a lot of things (e.g., base64 or quoted-printable encoding in emails, HTML entities, URL encoding, and so on). The documentation for i18n.commitEncoding and i18n.logOutputEncoding uses the phrase "character encoding" to make this more clear. Let's use that phrase in other places to make it clear what kind of encoding we are talking about. This patch covers the gui.encoding option, as well as the --encoding option for git-log, etc (in this latter case, I word-smithed the sentence a little at the same time). That, coupled with the mention of iconv in the --encoding description, should make this more clear. The other spot I looked at is the working-tree-encoding section of gitattributes(5). But it gives specific examples of encodings that I think make the meaning pretty clear already. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27logmsg_reencode(): warn when iconv() failsLibravatar Jeff King1-1/+3
If the user asks for a pretty-printed commit to be converted (either explicitly with --encoding=foo, or implicitly because the commit is non-utf8 and we want to convert it), we pass it through iconv(). If that fails, we fall back to showing the input verbatim, but don't tell the user that the output may be bogus. Let's add a warning to do so, along with a mention in the documentation for --encoding. Two things to note about the implementation: - we could produce the warning closer to the call to iconv() in reencode_string_len(), which would let us relay the value of errno. But this is not actually very helpful. reencode_string_len() does not know we are operating on a commit, and indeed does not know that the caller won't produce an error of its own. And the errno values from iconv() are seldom helpful (iconv_open() only ever produces EINVAL; perhaps EILSEQ from iconv() might be illuminating, but it can also return EINVAL for incomplete sequences). - if the reason for the failure is that the output charset is not supported, then the user will see this warning for every commit we try to display. That might be ugly and overwhelming, but on the other hand it is making it clear that every one of them has not been converted (and the likely outcome anyway is to re-try the command with a supported output encoding). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26column: fix parsing of the '--nl' optionLibravatar SZEDER Gábor1-1/+1
'git column's '--nl' option can be used to specify a "string to be printed at the end of each line" (quoting the man page), but this option and its mandatory argument has been parsed as OPT_INTEGER since the introduction of the command in 7e29b8254f (Add column layout skeleton and git-column, 2012-04-21). Consequently, any non-number argument is rejected by parse-options, and any number other than 0 leads to segfault: $ printf "%s\n" one two |git column --mode=plain --nl=foo error: option `nl' expects a numerical value $ printf "%s\n" one two |git column --mode=plain --nl=42 Segmentation fault (core dumped) $ printf "%s\n" one two |git column --mode=plain --nl=0 one two Parse this option as OPT_STRING. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-16Git 2.33Libravatar Junio C Hamano1-4/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-11Git 2.33-rc2Libravatar Junio C Hamano1-12/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-11Merge branch 'jn/log-m-does-not-imply-p'Libravatar Junio C Hamano1-4/+4
Earlier "git log -m" was changed to always produce patch output, which would break existing scripts, which has been reverted. * jn/log-m-does-not-imply-p: Revert 'diff-merges: let "-m" imply "-p"'
2021-08-09Revert 'diff-merges: let "-m" imply "-p"'Libravatar Jonathan Nieder1-4/+4
This reverts commit f5bfcc823ba242a46e20fb6f71c9fbf7ebb222fe, which made "git log -m" imply "--patch" by default. The logic was that "-m", which makes diff generation for merges perform a diff against each parent, has no use unless I am viewing the diff, so we could save the user some typing by turning on display of the resulting diff automatically. That wasn't expected to adversely affect scripts because scripts would either be using a command like "git diff-tree" that already emits diffs by default or would be combining -m with a diff generation option such as --name-status. By saving typing for interactive use without adversely affecting scripts in the wild, it would be a pure improvement. The problem is that although diff generation options are only relevant for the displayed diff, a script author can imagine them affecting path limiting. For example, I might run git log -w --format=%H -- README hoping to list commits that edited README, excluding whitespace-only changes. In fact, a whitespace-only change is not TREESAME so the use of -w here has no effect (since we don't apply these diff generation flags to the diff_options struct rev_info::pruning used for this purpose), but the documentation suggests that it should work Suppose you specified foo as the <paths>. We shall call commits that modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for foo, they look different and equal, respectively.) and a script author who has not tested whitespace-only changes wouldn't notice. Similarly, a script author could include git log -m --first-parent --format=%H -- README to filter the first-parent history for commits that modified README. The -m is a no-op but it reflects the script author's intent. For example, until 1e20a407fe2 (stash list: stop passing "-m" to "git log", 2021-05-21), "git stash list" did this. As a result, we can't safely change "-m" to imply "-p" without fear of breaking such scripts. Restore the previous behavior. Noticed because Rust's src/bootstrap/bootstrap.py made use of this same construct: https://github.com/rust-lang/rust/pull/87513. That script has been updated to omit the unnecessary "-m" option, but we can expect other scripts in the wild to have similar expectations. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: add coverage of the `ort` merge strategyLibravatar Elijah Newren1-0/+14
Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05git-rebase.txt: correct out-of-date and misleading text about renamesLibravatar Elijah Newren1-3/+1
Commit 58634dbff8 ("rebase: Allow merge strategies to be used when rebasing", 2006-06-21) added the --merge option to git-rebase so that renames could be detected (at least when using the `recursive` merge backend). However, git-am -3 gained that same ability in commit 579c9bb198 ("Use merge-recursive in git-am -3.", 2006-12-28). As such, the comment about being able to detect renames is not particularly noteworthy. Remove it. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: fix simple capitalization errorLibravatar Elijah Newren1-1/+1
Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: avoid giving special preference to patience algorithmLibravatar Elijah Newren1-5/+1
We already have diff-algorithm that explains why there are special diff algorithms, so we do not need to re-explain patience. patience exists as its own toplevel option for historical reasons, but there's no reason to give it special preference or document it again and suggest it's more important than other diff algorithms, so just refer to it as a deprecated shorthand for `diff-algorithm=patience`. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: do not imply using copy detection is desiredLibravatar Elijah Newren1-3/+3
Stating that the recursive strategy "currently cannot make use of detected copies" implies that this is a technical shortcoming of the current algorithm. I disagree with that. I don't see how copies could possibly be used in a sane fashion in a merge algorithm -- would we propagate changes in one file on one side of history to each copy of that file when merging? That makes no sense to me. I cannot think of anything else that would make sense either. Change the wording to simply state that we ignore any copies. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: update wording for the resolve strategyLibravatar Elijah Newren1-7/+6
It is probably helpful to cover the default merge strategy first, so move the text for the resolve strategy to later in the document. Further, the wording for "resolve" claimed that it was "considered generally safe and fast", which might imply in some readers minds that the same is not true of other strategies. Rather than adding this text to all the strategies, just remove it from this one. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05Documentation: edit awkward references to `git merge-recursive`Libravatar Elijah Newren3-9/+9
A few places in the documentation referred to the "`recursive` strategy" using the phrase "`git merge-recursive`", suggesting that it was forking subprocesses to call a toplevel builtin. Perhaps that was relevant to when rebase was a shell script, but it seems like a rather indirect way to refer to the `recursive` strategy. Simplify the references. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05directory-rename-detection.txt: small updates due to merge-ort optimizationsLibravatar Elijah Newren1-6/+8
In commit 0c4fd732f0 ("Move computation of dir_rename_count from merge-ort to diffcore-rename", 2021-02-27), much of the logic for computing directory renames moved into diffcore-rename. directory-rename-detection.txt had claims that all of that logic was found in merge-recursive. Update the documentation. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05git-rebase.txt: correct antiquated claims about --rebase-mergesLibravatar Elijah Newren1-6/+10
When --rebase-merges was first introduced, it only worked with the `recursive` strategy. Some time later, it gained support for merges using the `octopus` strategy. The limitation of only supporting these two strategies was documented in 25cff9f109 ("rebase -i --rebase-merges: add a section to the man page", 2018-04-25) and lifted in e145d99347 ("rebase -r: support merge strategies other than `recursive`", 2019-07-31). However, when the limitation was lifted, the documentation was not updated. Update it now. Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-04The eighth batchLibravatar Junio C Hamano1-1/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-04Merge branch 'ar/doc-markup-fix'Libravatar Junio C Hamano2-2/+2
Doc mark-up fix. * ar/doc-markup-fix: Documentation: render special characters correctly
2021-08-04Merge branch 'pb/merge-autostash-more'Libravatar Junio C Hamano1-1/+2
The local changes stashed by "git merge --autostash" were lost when the merge failed in certain ways, which has been corrected. * pb/merge-autostash-more: merge: apply autostash if merge strategy fails merge: apply autostash if fast-forward fails Documentation: define 'MERGE_AUTOSTASH' merge: add missing word "strategy" to a message
2021-08-04Merge branch 'ab/update-submitting-patches'Libravatar Junio C Hamano1-111/+96
Reorganize and update the SubmitingPatches document. * ab/update-submitting-patches: SubmittingPatches: replace discussion of Travis with GitHub Actions SubmittingPatches: move discussion of Signed-off-by above "send"
2021-08-02bundle doc: replace "basis" with "prerequsite(s)"Libravatar Ævar Arnfjörð Bjarmason1-7/+7
In the preceding commits we introduced new documentation that talks about "[commit|object] prerequsite(s)", but also faithfully moved around existing documentation that talks about the "basis". Let's change both that moved-around documentation and other existing documentation in the file to consistently use "[commit|object]" prerequisite(s)" instead of talking about "basis". The mention of "basis" isn't wrong, but readers will be helped by us using only one term throughout the document for this concept. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02bundle doc: elaborate on rev<->ref restrictionLibravatar Ævar Arnfjörð Bjarmason1-8/+38
Elaborate on the restriction that you cannot provide a revision that doesn't resolve to a reference in the "SPECIFYING REFERENCES" section with examples. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02bundle doc: elaborate on object prerequisitesLibravatar Ævar Arnfjörð Bjarmason1-3/+34
Split out the discussion bout "object prerequisites" into its own section, and add some more examples of the common cases. See 2e0afafebd (Add git-bundle: move objects and references by archive, 2007-02-22) for the introduction of the documentation being changed here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02bundle doc: rewrite the "DESCRIPTION" sectionLibravatar Ævar Arnfjörð Bjarmason1-15/+41
Rewrite the "DESCRIPTION" section for "git bundle" to start by talking about what bundles are in general terms, rather than diving directly into one example of what they might be used for. This changes documentation that's been substantially the same ever since the command was added in 2e0afafebd8 (Add git-bundle: move objects and references by archive, 2007-02-22). I've split up the DESCRIPTION into that section and a "BUNDLE FORMAT" section, it briefly discusses the format, but then links to the technical/bundle-format.txt documentation. The "the user must specify a basis" part of this is discussed below in "SPECIFYING REFERENCES", and will be further elaborated on in a subsequent commit. So I'm removing that part and letting the mention of "revision exclusions" suffice. There was a discussion about whether to say anything at all about "thin packs" here[1]. I think it's good to mention it for the curious reader willing to read the technical docs, but let's explicitly say that there's no "thick pack", and that the difference shouldn't matter. 1. http://lore.kernel.org/git/xmqqk0mbt5rj.fsf@gitster.g Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02Git 2.33-rc0Libravatar Junio C Hamano1-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02Merge branch 'fc/pull-no-rebase-merges-theirs-into-ours'Libravatar Junio C Hamano1-1/+1
Documentation fix for "git pull --rebase=no". * fc/pull-no-rebase-merges-theirs-into-ours: doc: pull: fix rebase=false documentation
2021-08-02Merge branch 'jk/config-env-doc'Libravatar Junio C Hamano1-11/+17
Documentation around GIT_CONFIG has been updated. * jk/config-env-doc: doc/git-config: simplify "override" advice for FILES section doc/git-config: clarify GIT_CONFIG environment variable doc/git-config: explain --file instead of referring to GIT_CONFIG
2021-08-02Merge branch 'pb/submodule-recurse-doc'Libravatar Junio C Hamano1-2/+3
Doc update. * pb/submodule-recurse-doc: doc: clarify description of 'submodule.recurse'
2021-07-30Documentation: render special characters correctlyLibravatar Andrei Rybak2-2/+2
Three hyphens are rendered verbatim, so "--" has to be used to produce a dash. There is no double arrow ("<->" is rendered as "<→"), so a left and right arrow "<-->" have to be combined for that. So fix asciidoc output for special characters. This is similar to fixes in commit de82095a95 (doc hash-function-transition: fix asciidoc output, 2021-02-05). Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-28The seventh batchLibravatar Junio C Hamano1-0/+43
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-28Merge branch 'en/rename-limits-doc'Libravatar Junio C Hamano3-12/+21
Documentation on "git diff -l<n>" and diff.renameLimit have been updated, and the defaults for these limits have been raised. * en/rename-limits-doc: rename: bump limit defaults yet again diffcore-rename: treat a rename_limit of 0 as unlimited doc: clarify documentation for rename/copy limits diff: correct warning message when renameLimit exceeded
2021-07-28Merge branch 'ds/gender-neutral-doc-guidelines'Libravatar Junio C Hamano1-0/+45
A guideline for gender neutral documentation has been added. * ds/gender-neutral-doc-guidelines: CodingGuidelines: recommend gender-neutral description
2021-07-28Merge branch 'dl/diff-merge-base'Libravatar Junio C Hamano1-3/+7
"git diff --merge-base" documentation has been updated. * dl/diff-merge-base: git-diff: fix missing --merge-base docs