Hi Duy, On Thu, 17 Mar 2016, Duy Nguyen wrote: > On Thu, Mar 17, 2016 at 8:04 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > 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?) Yes, I tested the untracked cache and enabled it in a couple of my repositories. It works great. But it has little to do with the exclude engine ;-) > 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. Oh, I see. Unfortunately, this does not help me at all. In the use case I am trying to get to work fast, we have tons and tons of directories and need *one* file in pretty much *all* of those directories, and exclude most of the other files. To make matters even worse, the list of excluded (or included) files is constantly changing. > 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). Thanks! Dscho -- 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