Re: bug: sparse config interpretation incorrectness in 2.8.0-rc2

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Duy,

On Thu, 17 Mar 2016, Duy Nguyen wrote:

> On Thu, Mar 17, 2016 at 8:04 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> 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