{"thread":{"id":"48650","subject":"[RFC PATCH 1/2] docs: reflect supported fetch options of git pull","startedAt":"2018-06-04T21:51:00Z","lastAt":"2018-06-05T20:46:27Z","messageCount":4,"participants":["Rafael Ascensão","Duy Nguyen"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"349298","messageId":"20180604215023.20525-1-rafa.almas@gmail.com","threadId":"48650","inReplyTo":null,"subject":"[RFC PATCH 1/2] docs: reflect supported fetch options of git pull","fromName":"Rafael Ascensão","fromEmail":"rafa.almas@gmail.com","sentAt":"2018-06-04T21:50:22Z","receivedAt":"2018-06-04T21:51:00Z","isPatch":true,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"`git pull` understands some options of `git fetch` which then uses in\nits operation. The documentation of `git pull` doesn't reflect this\nclearly, showing options that are not yet supported (e.g. `--deepen`)\nand omitting options that are supported (e.g. `--prune`).\n\nMake the documentation consistent with present behaviour by hiding\nunavailable options only.\n\nReported-by: Marius Giurgi \nSigned-off-by: Rafael Ascensão \n---\n\nMarius asked on freenode.#git if pull supported `--prune`, upon\ninspection seems like the man page was missing some of the supported\noptions and listing others that are not supported via pull.\n\nHere's a quick summary of the changes to pull's documentation:\n\nadd: remove:\n --dry-run --deepen=\n -p, --prune --shallow-since=\n --refmap= --shallow-exclude=\n -t, --tags -u, --update-head-ok\n -j, --jobs=\n\n Documentation/fetch-options.txt | 20 +++++++++++++-------\n 1 file changed, 13 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 8631e365f..da17d27c1 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -14,6 +14,7 @@\n \tlinkgit:git-clone[1]), deepen or shorten the history to the specified\n \tnumber of commits. Tags for the deepened commits are not fetched.\n \n+ifndef::git-pull[]\n --deepen=::\n \tSimilar to --depth, except it specifies the number of commits\n \tfrom the current shallow boundary instead of from the tip of\n@@ -27,6 +28,7 @@\n \tDeepen or shorten the history of a shallow repository to\n \texclude commits reachable from a specified remote branch or tag.\n \tThis option can be specified multiple times.\n+endif::git-pull[]\n \n --unshallow::\n \tIf the source repository is complete, convert a shallow\n@@ -42,10 +44,8 @@ the current repository has the same history as the source repository.\n \t.git/shallow. This option updates .git/shallow and accept such\n \trefs.\n \n-ifndef::git-pull[]\n --dry-run::\n \tShow what would be done, without making any changes.\n-endif::git-pull[]\n \n -f::\n --force::\n@@ -63,6 +63,7 @@ ifndef::git-pull[]\n --multiple::\n \tAllow several and arguments to be\n \tspecified. No s may be specified.\n+endif::git-pull[]\n \n -p::\n --prune::\n@@ -76,8 +77,14 @@ ifndef::git-pull[]\n \tsubject to pruning. Supplying `--prune-tags` is a shorthand for\n \tproviding the tag refspec.\n +\n+ifdef::git-pull[]\n+See the PRUNING section on linkgit:git-fetch[1] for more details.\n+endif::git-pull[]\n+ifndef::git-pull[]\n See the PRUNING section below for more details.\n+endif::git-pull[]\n \n+ifndef::git-pull[]\n -P::\n --prune-tags::\n \tBefore fetching, remove any local tags that no longer exist on\n@@ -89,9 +96,6 @@ See the PRUNING section below for more details.\n +\n See the PRUNING section below for more details.\n \n-endif::git-pull[]\n-\n-ifndef::git-pull[]\n -n::\n endif::git-pull[]\n --no-tags::\n@@ -101,7 +105,6 @@ endif::git-pull[]\n \tbehavior for a remote may be specified with the remote..tagOpt\n \tsetting. See linkgit:git-config[1].\n \n-ifndef::git-pull[]\n --refmap=::\n \tWhen fetching refs listed on the command line, use the\n \tspecified refspec (can be given more than once) to map the\n@@ -119,6 +122,7 @@ ifndef::git-pull[]\n \tis used (though tags may be pruned anyway if they are also the\n \tdestination of an explicit refspec; see `--prune`).\n \n+ifndef::git-pull[]\n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n \tpopulated submodules should be fetched too. It can be used as a\n@@ -129,6 +133,7 @@ ifndef::git-pull[]\n \twhen the superproject retrieves a commit that updates the submodule's\n \treference to a commit that isn't already in the local submodule\n \tclone.\n+endif::git-pull[]\n \n -j::\n --jobs=::\n@@ -137,6 +142,7 @@ ifndef::git-pull[]\n \tsubmodules will be faster. By default submodules will be fetched\n \tone at a time.\n \n+ifndef::git-pull[]\n --no-recurse-submodules::\n \tDisable recursive fetching of submodules (this has the same effect as\n \tusing the `--recurse-submodules=no` option).\n@@ -153,7 +159,6 @@ ifndef::git-pull[]\n \trecursion (such as settings in linkgit:gitmodules[5] and\n \tlinkgit:git-config[1]) override this option, as does\n \tspecifying --[no-]recurse-submodules directly.\n-endif::git-pull[]\n \n -u::\n --update-head-ok::\n@@ -163,6 +168,7 @@ endif::git-pull[]\n \tto communicate with 'git fetch', and unless you are\n \timplementing your own Porcelain you are not supposed to\n \tuse it.\n+endif::git-pull[]\n \n --upload-pack ::\n \tWhen given, and the repository to fetch from is handled\n-- \n2.17.1\n\n"},{"id":"349299","messageId":"20180604215023.20525-2-rafa.almas@gmail.com","threadId":"48650","inReplyTo":"20180604215023.20525-1-rafa.almas@gmail.com","subject":"[RFC PATCH 2/2] pull: allow -e as a synonym for --edit","fromName":"Rafael Ascensão","fromEmail":"rafa.almas@gmail.com","sentAt":"2018-06-04T21:50:23Z","receivedAt":"2018-06-04T21:51:05Z","isPatch":true,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"`git pull`'s documentation mentions that `--edit` can be used with short\noption `-e`. But `git pull` doesn't understand `-e`.\n\nTo make things consistent, teach `git pull` `-e` for `--edit`\n\nSigned-off-by: Rafael Ascensão \n---\n builtin/pull.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex e32d6cd5b..dd54f2e57 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -154,7 +154,7 @@ static struct option pull_options[] = {\n \tOPT_PASSTHRU(0, \"commit\", &opt_commit, NULL,\n \t\tN_(\"perform a commit if the merge succeeds (default)\"),\n \t\tPARSE_OPT_NOARG),\n-\tOPT_PASSTHRU(0, \"edit\", &opt_edit, NULL,\n+\tOPT_PASSTHRU('e', \"edit\", &opt_edit, NULL,\n \t\tN_(\"edit message before committing\"),\n \t\tPARSE_OPT_NOARG),\n \tOPT_PASSTHRU(0, \"ff\", &opt_ff, NULL,\n-- \n2.17.1\n\n"},{"id":"349359","messageId":"CACsJy8DVi0rqjw0dCdxppb=e+jH5yNcX9XcRXDnvLXS8x0QsJA@mail.gmail.com","threadId":"48650","inReplyTo":"20180604215023.20525-1-rafa.almas@gmail.com","subject":"Re: [RFC PATCH 1/2] docs: reflect supported fetch options of git pull","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-06-05T16:05:56Z","receivedAt":"2018-06-05T16:06:31Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Jun 4, 2018 at 11:50 PM, Rafael Ascensão wrote:\n> `git pull` understands some options of `git fetch` which then uses in\n> its operation. The documentation of `git pull` doesn't reflect this\n> clearly, showing options that are not yet supported (e.g. `--deepen`)\n> and omitting options that are supported (e.g. `--prune`).\n>\n> Make the documentation consistent with present behaviour by hiding\n> unavailable options only.\n\nA better option may be making git-pull accept those options as well. I\nsee no reason git-pull should support options that git-fetch does (at\nleast most of them). But I would understand if you would not want to\ngo touch the code. It's basically a couple of OPT_PASSTRHU though so\nnot very hard to do.\n\nPS. Anybody up to making parse-options accept multiple struct option\narrays? This way we can have much better option passthru without\nspecifying them again and again.\n\n>\n> Reported-by: Marius Giurgi \n> Signed-off-by: Rafael Ascensão \n> ---\n>\n> Marius asked on freenode.#git if pull supported `--prune`, upon\n> inspection seems like the man page was missing some of the supported\n> options and listing others that are not supported via pull.\n>\n> Here's a quick summary of the changes to pull's documentation:\n>\n> add: remove:\n> --dry-run --deepen=\n> -p, --prune --shallow-since=\n> --refmap= --shallow-exclude=\n> -t, --tags -u, --update-head-ok\n> -j, --jobs=\n>\n> Documentation/fetch-options.txt | 20 +++++++++++++-------\n> 1 file changed, 13 insertions(+), 7 deletions(-)\n>\n> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\n> index 8631e365f..da17d27c1 100644\n> --- a/Documentation/fetch-options.txt\n> +++ b/Documentation/fetch-options.txt\n> @@ -14,6 +14,7 @@\n> linkgit:git-clone[1]), deepen or shorten the history to the specified\n> number of commits. Tags for the deepened commits are not fetched.\n>\n> +ifndef::git-pull[]\n> --deepen=::\n> Similar to --depth, except it specifies the number of commits\n> from the current shallow boundary instead of from the tip of\n> @@ -27,6 +28,7 @@\n> Deepen or shorten the history of a shallow repository to\n> exclude commits reachable from a specified remote branch or tag.\n> This option can be specified multiple times.\n> +endif::git-pull[]\n>\n> --unshallow::\n> If the source repository is complete, convert a shallow\n> @@ -42,10 +44,8 @@ the current repository has the same history as the source repository.\n> .git/shallow. This option updates .git/shallow and accept such\n> refs.\n>\n> -ifndef::git-pull[]\n> --dry-run::\n> Show what would be done, without making any changes.\n> -endif::git-pull[]\n>\n> -f::\n> --force::\n> @@ -63,6 +63,7 @@ ifndef::git-pull[]\n> --multiple::\n> Allow several and arguments to be\n> specified. No s may be specified.\n> +endif::git-pull[]\n>\n> -p::\n> --prune::\n> @@ -76,8 +77,14 @@ ifndef::git-pull[]\n> subject to pruning. Supplying `--prune-tags` is a shorthand for\n> providing the tag refspec.\n> +\n> +ifdef::git-pull[]\n> +See the PRUNING section on linkgit:git-fetch[1] for more details.\n> +endif::git-pull[]\n> +ifndef::git-pull[]\n> See the PRUNING section below for more details.\n> +endif::git-pull[]\n>\n> +ifndef::git-pull[]\n> -P::\n> --prune-tags::\n> Before fetching, remove any local tags that no longer exist on\n> @@ -89,9 +96,6 @@ See the PRUNING section below for more details.\n> +\n> See the PRUNING section below for more details.\n>\n> -endif::git-pull[]\n> -\n> -ifndef::git-pull[]\n> -n::\n> endif::git-pull[]\n> --no-tags::\n> @@ -101,7 +105,6 @@ endif::git-pull[]\n> behavior for a remote may be specified with the remote..tagOpt\n> setting. See linkgit:git-config[1].\n>\n> -ifndef::git-pull[]\n> --refmap=::\n> When fetching refs listed on the command line, use the\n> specified refspec (can be given more than once) to map the\n> @@ -119,6 +122,7 @@ ifndef::git-pull[]\n> is used (though tags may be pruned anyway if they are also the\n> destination of an explicit refspec; see `--prune`).\n>\n> +ifndef::git-pull[]\n> --recurse-submodules[=yes|on-demand|no]::\n> This option controls if and under what conditions new commits of\n> populated submodules should be fetched too. It can be used as a\n> @@ -129,6 +133,7 @@ ifndef::git-pull[]\n> when the superproject retrieves a commit that updates the submodule's\n> reference to a commit that isn't already in the local submodule\n> clone.\n> +endif::git-pull[]\n>\n> -j::\n> --jobs=::\n> @@ -137,6 +142,7 @@ ifndef::git-pull[]\n> submodules will be faster. By default submodules will be fetched\n> one at a time.\n>\n> +ifndef::git-pull[]\n> --no-recurse-submodules::\n> Disable recursive fetching of submodules (this has the same effect as\n> using the `--recurse-submodules=no` option).\n> @@ -153,7 +159,6 @@ ifndef::git-pull[]\n> recursion (such as settings in linkgit:gitmodules[5] and\n> linkgit:git-config[1]) override this option, as does\n> specifying --[no-]recurse-submodules directly.\n> -endif::git-pull[]\n>\n> -u::\n> --update-head-ok::\n> @@ -163,6 +168,7 @@ endif::git-pull[]\n> to communicate with 'git fetch', and unless you are\n> implementing your own Porcelain you are not supposed to\n> use it.\n> +endif::git-pull[]\n>\n> --upload-pack ::\n> When given, and the repository to fetch from is handled\n> --\n> 2.17.1\n>\n\n\n\n-- \nDuy\n"},{"id":"349395","messageId":"20180605204607.GA4679@rigel","threadId":"48650","inReplyTo":"CACsJy8DVi0rqjw0dCdxppb=e+jH5yNcX9XcRXDnvLXS8x0QsJA@mail.gmail.com","subject":"Re: [RFC PATCH 1/2] docs: reflect supported fetch options of git pull","fromName":"Rafael Ascensão","fromEmail":"rafa.almas@gmail.com","sentAt":"2018-06-05T20:46:07Z","receivedAt":"2018-06-05T20:46:27Z","isPatch":true,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"On Tue, Jun 05, 2018 at 06:05:56PM +0200, Duy Nguyen wrote:\n> A better option may be making git-pull accept those options as well. I\n> see no reason git-pull should support options that git-fetch does (at\n> least most of them).\n\nI sent this as a RFC, mostly to discuss what is the correct path to\nfollow. Updating the documentation was trivial and would still be useful\nif nothing came out from this.\n\n> It's basically a couple of OPT_PASSTRHU though so not very hard to do.\n\nMy impression was that in the past git was very permissive on adding new\noptions but nowadays it tries exercise more restraint. But not sure how\nrelevant this is anyways, as pull already supports the majority of the\noptions from both `fetch` and `merge`.\n\n> PS. Anybody up to making parse-options accept multiple struct option\n> arrays? This way we can have much better option passthru without\n> specifying them again and again.\n\nIf the path is adding just couple of OPT_PASSTRHU, I could do it. But\nI'll wait and see if someone picks your parse-options suggestion.\n\nThanks for the review.\n\n--\nRafael Ascensão\n"}]}