On Thu, Mar 17, 2016 at 8:04 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Duy, > > On Thu, 17 Mar 2016, Duy Nguyen wrote: > >> Good news for you is there's "sparse checkout v2" in the work, that >> would not rely on exclude engine and should be both faster and more >> elegant. That should reduce "sparse checkout v1" usage to really small >> cases. > > I dabbled myself with speeding up the entire exclude engine (essentially, > I use a hash map of the non-wildcard prefixes to the corresponding line > number). So I am interested to see what your approach is. Could you point > me to it (I did not see any obvious branch in your GitHub space)? First of all it's not about speeding up exclude engine. I think I did that (sort of) already with untracked cache (have you tried it on Windows?) It's Junio's idea actually, what I'm implementing. The index contains a list of _files_ yes? What if the index contains also _directories_? Of course we can't "refresh" or check if the whole directory is "dirty" like a file, so those dirs will stay registered in the index, but be entirely missing from worktree. The effect is the same as sparse checkout, except that we keep all "hidden" files of sparse checkout in the index. In fact I plan to reuse CE_SKIP_WORKTREE (from sparse checkout) to mark those dirs. The advantage is obvious: the index can be much smaller, which leads to faster update and access. Of course now you can only hide either whole directory, or hide nothing. It's less flexible than sparse checkout "v1", but you can use "v1" on top of "v2" for that. Changing checkout regions involves unfolding or folding certain directories, sparse patterns are not used. If you are still curious, you can check out my 'narrow-checkout' branch on github. The basic is working. Folding/unfolding is not. Be warned that it's even dirtier than your rebase-helper branch (and will not be released any time soon either, lots of other stuff to be finished first). -- Duy -- 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