From: Junio C Hamano <firstname.lastname@example.org> To: "Teng Long via GitGitGadget" <email@example.com> Cc: firstname.lastname@example.org, Teng Long <email@example.com> Subject: Re: [PATCH] clone: document partial clone section Date: Thu, 02 Apr 2020 10:37:23 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Teng Long via GitGitGadget's message of "Thu, 02 Apr 2020 02:02:26 +0000") "Teng Long via GitGitGadget" <firstname.lastname@example.org> writes: > From: Dyrone Teng <email@example.com> > > Partial clones are created using 'git clone', but there is no related > help information in the git-clone documentation during a period. Add > a relevant section to help users understand what partial clones are > and how they differ from normal clones. I am not sure what "during a period" means there; perhaps we can simplydrop these three words to make the sentence clearer without changing what you wanted to say? > The section briefly introduces the applicable scenarios and some > precautions of partial clone. If users want to know more about its > technical design and other details, users can view the link of > git-partial-clone(7) according to the guidelines in the section. Otherwise, the above is a nice and clearly written summary. > Signed-off-by: Teng Long <firstname.lastname@example.org> As Derrick pointed out, we want to see the authors sign their patches using the same authors' name on this line. > diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt > index bf24f1813ad..dd92d153535 100644 > --- a/Documentation/git-clone.txt > +++ b/Documentation/git-clone.txt > @@ -297,6 +297,75 @@ or `--mirror` is given) > for `host.xz:foo/.git`). Cloning into an existing directory > is only allowed if the directory is empty. > > +Partial Clone > +------------- > + > +By default, `git clone` will download every reachable object, including > +every version of every file in the history of the repository. The **partial clone** Please avoid overly long lines. > +... omitted from the initial `git clone` and subsequent `git fetch` > +operations. In this way, a partial clone can reduce the network traffic > +costs and disk space usage when git is working under a large repository. Perhaps "can reduce the initial network traffic costs...", as you'd end up paying the cost for the part of the repository you'd actually use. And there is traffic and disk usage reduction that comes but not "in this way (i.e. initial clone does not have to transfer)", which is that parts of the trees and histories you never touch may not have to be transferred and stored at all. If you meant to cover benefits coming from both reasons, perhaps omit "In this way, " and then we do not have to say "the initial network traffic costs...". Or you may want to spell out both a bit more explicitly. > +To use the partial clone feature, you can run `git clone` with the > +`--filter=<filter-spec>` option. If the repository has a deep history > +and you don't want to download any blobs, the form `filter=blob:none` > +will omit all the blobs. If the repository of a young project simply has a large collection of files, blob:none would still omit all the blobs, so I am not sure if "the repository has a deep history and" is a good thing to say. > +When using a partial clone, Git will request missing objects from the > +remote(s) when necessary. Several commands that do not involve a request > +over a network may now trigger these requests. We may want to phrase this a bit stronger, if you are listing these as pros-and-cons? E.g. "Some 'local' commands may fail without a network connection to the remote repository." > +For example, The <repository> contains two branches which names 'master' > +and 'topic. Then, we clone the repository by > + > + $ git clone --filter=blob:none --no-checkout <repository> > + > +With the `--filter=blob:none` option Git will omit all the blobs and > +the `--no-checkout` option Git will not perform a checkout of HEAD > +after the clone is complete. Then, we check out the remote tracking > +'topic' branch by > + > + $ git checkout -b topic origin/topic > + > +The output looks like > + > +------------ > + remote: Enumerating objects: 1, done. > + remote: Counting objects: 100% (1/1), done. > + remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 > + Receiving objects: 100% (1/1), 43 bytes | 43.00 KiB/s, done. > + Branch 'topic' set up to track remote branch 'topic' from 'origin'. > + Switched to a new branch 'topic' > +------------ > + > +The output is a bit surprising but it shows how partial clone works. > +When we check out the branch 'topic' Git will request the missing blobs > +because they are needed. Then, We can switch back to branch 'master' by > + > + $ git checkout master > + > +This time the output looks like > + > +------------ > + Switched to branch 'master' > + Your branch is up to date with 'origin/master'. > +------------ > + > +It shows that when we switch back to the previous location, the checkout > +is done without a download because the repository has all the blobs that > +were downloaded previously. Good illusration. Nicely done. > +`git log` may also make a surprise with partial clones. `git log > +--<path>` will not cause downloads with the blob filters, because it's You meant to leave a SP between double-dash and <pathspec> (these things are called <pathspec> and not necessarily a <path>, so use the right word) here. > +only reading commits. This is incorrect. A pathspec limited "log" reads both commits and trees. Luckily, that does not change the conclusion---a blob-less partial clone already has all tree objects in addition to commit objects, so there is no need for lazy/on-demand fetching. > `git log -p -- <path>` will download blobs to > +generate the patch output and git log --raw will download all blobs > +that changed at recent commits in order to compute renames. I do not know anybody sane uses '--raw' these days, but a better way to describe this may be In addition to any options that require git to look at the contents of blobs, like "-p" and "--stat", options that cause git to report pathnames, like "--summary" and "--raw", will trigger lazy/on-demand fetching of blobs, as they are needed to detect inexact renames. Thanks.
next prev parent reply other threads:[~2020-04-02 17:37 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-02 2:02 Teng Long via GitGitGadget 2020-04-02 11:29 ` Derrick Stolee 2020-04-02 17:37 ` Junio C Hamano [this message] 2020-04-02 17:52 ` Derrick Stolee 2020-04-13 15:25 ` [PATCH v2 0/3] " Teng Long via GitGitGadget 2020-04-13 15:25 ` [PATCH v2 1/3] partial-clone: set default filter with --partial Derrick Stolee via GitGitGadget 2020-04-13 15:25 ` [PATCH v2 2/3] clone: document --partial and --filter options Derrick Stolee via GitGitGadget 2020-04-13 15:26 ` [PATCH v2 3/3] clone: document partial clone section Dyrone Teng via GitGitGadget 2020-10-27 13:41 ` Philippe Blain 2020-04-13 22:45 ` [PATCH v2 0/3] " Junio C Hamano 2020-04-14 13:43 ` Derrick Stolee 2020-04-14 16:25 ` Junio C Hamano 2020-04-14 16:26 ` Derrick Stolee 2020-04-14 13:42 ` Derrick Stolee 2020-10-27 3:12 ` [PATCH v3] " Teng Long via GitGitGadget 2020-10-27 13:13 ` Philippe Blain 2020-10-27 18:51 ` Junio C Hamano 2021-02-25 9:13 ` [PATCH v4] " Teng Long via GitGitGadget 2021-02-25 13:38 ` Philippe Blain 2021-03-02 14:25 ` [PATCH v5] " Teng Long via GitGitGadget 2021-03-03 19:25 ` Junio C Hamano 2021-05-06 6:27 ` Fix inconsistent signed-off-by abd author name Teng Long 2021-05-06 6:30 ` [PATCH 1/1] clone: document partial clone section Teng Long 2021-05-07 4:00 ` Bagas Sanjaya
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] clone: document partial clone section' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).