From: Elijah Newren <newren@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [RFC PATCH 06/15] Automatically reuse sparse limiting arguments in revision walking
Date: Sat, 4 Sep 2010 22:50:34 -0600 [thread overview]
Message-ID: <AANLkTi=ywOZfkxfr1Gt3AMMbWDphKjTBudG=E4+xer-P@mail.gmail.com> (raw)
In-Reply-To: <AANLkTik1E=7Uawq-fGXppac3ur-oohq104A5wEgxv8cL@mail.gmail.com>
On Sat, Sep 4, 2010 at 7:58 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Sun, Sep 5, 2010 at 10:13 AM, Elijah Newren <newren@gmail.com> wrote:
>> In a sparse repository, by automatically making use of sparse limits
>> specified at clone time, we can avoid walking uninteresting commits and
>
> I have a nicer approach here. Instead of modifying setup_revisions()
> and similar functions, I update get_pathspec() to rewrite the
> pathspecs from command line in narrow/shallow repos. get_pathspec()
> currently does some form of rewriting already (prepending prefix).
>
> So if you do "git log", get_pathspec() would return "git log -- PATH1
> PATH2...". Will repost my series soon, or I can send that particular
> patch to you.
Ooh, that's clever. I like it. Do you also do verification that any
paths specified by the user are a subset of the paths the sparse clone
is limited to? That'd be really nice. Much better than my simple
dumb "just append" logic.
How do you reconcile conflicting needs, though? For most cases,
whenever the user specifies paths, get_pathspec should make sure those
paths are a subset of the sparse paths (throwing an error if they're
not) and then just use the user-specified ones. However, I think
doing this in all cases would break ls-files/cat-file -p, as the
pathspecs passed to those are not necessarily rooted at the toplevel
of the repository (and the prefix doesn't correct for that either).
Also, when no paths are specified by the user, the correct answer can
still vary by command. ls-tree should be given no pathspecs in such a
case, even in a sparse clone. Nor should commit (it wouldn't hurt too
bad to send it the sparse pathspecs, though it'd send commit through
the "partial commit" section of the code base each time rather than
the "as-is commit" section, which seems suboptimal). And on the other
end of the spectrum, log/rev-list/diff should all take the sparse
pathspecs in such a case.
next prev parent reply other threads:[~2010-09-05 4:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 0:13 [RFC PATCH 00/15] Sparse clones Elijah Newren
2010-09-05 0:13 ` [RFC PATCH 01/15] README-sparse-clone: Add a basic writeup of my ideas for sparse clones Elijah Newren
2010-09-05 3:01 ` Nguyen Thai Ngoc Duy
2010-09-05 3:13 ` Elijah Newren
2010-09-06 3:14 ` Nguyen Thai Ngoc Duy
2010-09-05 0:13 ` [RFC PATCH 02/15] Add tests for client handling in a sparse repository Elijah Newren
2010-09-05 0:13 ` [RFC PATCH 03/15] Read sparse limiting args from $GIT_DIR/sparse-limit Elijah Newren
2010-09-05 0:13 ` [RFC PATCH 04/15] When unpacking in a sparse repository, avoid traversing missing trees/blobs Elijah Newren
2010-09-05 0:13 ` [RFC PATCH 05/15] read_tree_recursive: Avoid missing blobs and trees in a sparse repository Elijah Newren
2010-09-05 2:00 ` Nguyen Thai Ngoc Duy
2010-09-05 3:16 ` Elijah Newren
2010-09-05 4:31 ` Elijah Newren
2010-09-05 0:13 ` [RFC PATCH 06/15] Automatically reuse sparse limiting arguments in revision walking Elijah Newren
2010-09-05 1:58 ` Nguyen Thai Ngoc Duy
2010-09-05 4:50 ` Elijah Newren [this message]
2010-09-05 7:12 ` Nguyen Thai Ngoc Duy
2010-09-05 0:13 ` [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index Elijah Newren
2010-09-05 7:54 ` Nguyen Thai Ngoc Duy
2010-09-05 21:09 ` Elijah Newren
2010-09-06 4:42 ` Elijah Newren
2010-09-06 5:02 ` Nguyen Thai Ngoc Duy
2010-09-06 4:47 ` [PATCH 0/4] en/object-list-with-pathspec update Nguyễn Thái Ngọc Duy
2010-09-06 4:47 ` [PATCH 1/4] Add testcases showing how pathspecs are ignored with rev-list --objects Nguyễn Thái Ngọc Duy
2010-09-06 4:47 ` [PATCH 2/4] tree-walk: copy tree_entry_interesting() as is from tree-diff.c Nguyễn Thái Ngọc Duy
2010-09-06 15:22 ` Elijah Newren
2010-09-06 22:09 ` Nguyen Thai Ngoc Duy
2010-09-06 4:47 ` [PATCH 3/4] tree-walk: actually move tree_entry_interesting() to tree-walk.c Nguyễn Thái Ngọc Duy
2010-09-06 15:31 ` Elijah Newren
2010-09-06 22:20 ` Nguyen Thai Ngoc Duy
2010-09-06 23:53 ` Junio C Hamano
2010-09-06 4:47 ` [PATCH 4/4] Make rev-list --objects work together with pathspecs Nguyễn Thái Ngọc Duy
2010-09-07 1:28 ` [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index Nguyen Thai Ngoc Duy
2010-09-07 3:06 ` Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 08/15] cache_tree_update(): Require relevant tree to be passed Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 09/15] Add tests for communication dealing with sparse repositories Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 10/15] sparse-repo: Provide a function to record sparse limiting arguments Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 11/15] builtin-clone: Accept paths for sparse clone Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 12/15] Pass extra (rev-list) args on, at least in some cases Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 13/15] upload-pack: Handle extra rev-list arguments being passed Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 14/15] EVIL COMMIT: Include all commits Elijah Newren
2010-09-05 0:14 ` [RFC PATCH 15/15] clone: Ensure sparse limiting arguments are used in subsequent operations Elijah Newren
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=ywOZfkxfr1Gt3AMMbWDphKjTBudG=E4+xer-P@mail.gmail.com' \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).