On Sat, Sep 4, 2010 at 7:58 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Sun, Sep 5, 2010 at 10:13 AM, Elijah Newren <newren@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html