| Message ID | c94f8c43-625c-8e99-fa04-aafb0c7cdd78@web.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | None | expand |
Hi René, This patch (and the other one attached to this thread) both look good. However, the numbering on this patch is a little weird, (2/1? 3/1?). Is there a third patch missing, and/or are your subject lines mangled? Please share if there is more, or if I should be interpreting this series differently. Otherwise this patch makes sense. On Sat, Mar 28, 2020 at 03:48:33PM +0100, René Scharfe wrote: > 'git pull' implicitly passes --update-head-ok to 'git fetch', but > doesn't itself accept that option from users. That makes sense, as it > wouldn't work without the possibility to update HEAD. Remove the option > from the command's documentation to match its actual behavior. > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > Documentation/fetch-options.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt > index 00d03ec8c3..05709f67a1 100644 > --- a/Documentation/fetch-options.txt > +++ b/Documentation/fetch-options.txt > @@ -204,7 +204,6 @@ ifndef::git-pull[] > recursion (such as settings in linkgit:gitmodules[5] and > linkgit:git-config[1]) override this option, as does > specifying --[no-]recurse-submodules directly. > -endif::git-pull[] > > -u:: > --update-head-ok:: > @@ -214,6 +213,7 @@ endif::git-pull[] > to communicate with 'git fetch', and unless you are > implementing your own Porcelain you are not supposed to > use it. > +endif::git-pull[] > > --upload-pack <upload-pack>:: > When given, and the repository to fetch from is handled > -- > 2.26.0 Thanks, Taylor
Am 31.03.20 um 23:48 schrieb Taylor Blau: > This patch (and the other one attached to this thread) both look good. > However, the numbering on this patch is a little weird, (2/1? 3/1?). Is > there a third patch missing, and/or are your subject lines mangled? > > Please share if there is more, or if I should be interpreting this > series differently. Otherwise this patch makes sense. The first patch was https://lore.kernel.org/git/a406c273-9a2c-72ed-c5e3-4c19848f0f94@web.de/ and I meant to only send that one. A few weeks later I couldn't help but follow up with two more patches. I don't plan to continue the series any further. René
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 00d03ec8c3..05709f67a1 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -204,7 +204,6 @@ ifndef::git-pull[] recursion (such as settings in linkgit:gitmodules[5] and linkgit:git-config[1]) override this option, as does specifying --[no-]recurse-submodules directly. -endif::git-pull[] -u:: --update-head-ok:: @@ -214,6 +213,7 @@ endif::git-pull[] to communicate with 'git fetch', and unless you are implementing your own Porcelain you are not supposed to use it. +endif::git-pull[] --upload-pack <upload-pack>:: When given, and the repository to fetch from is handled
'git pull' implicitly passes --update-head-ok to 'git fetch', but doesn't itself accept that option from users. That makes sense, as it wouldn't work without the possibility to update HEAD. Remove the option from the command's documentation to match its actual behavior. Signed-off-by: René Scharfe <l.s.r@web.de> --- Documentation/fetch-options.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.26.0