Git 1.7.6: Sparse checkouts do not work with directory exclusions

Sometime after Git 1.7.3.2, sparse checkouts stopped working for me.  My 
sparse-checkout file looks something like:

*
!DirA/
!DirB/
DirC/

I have restored some lines of code that were removed in November 2010.  
This resolves the sparse checkout issue for me, but my guess is the 
solution is not implemented properly.

Can anyone confirm the issue and describe why those lines were removed?

Thanks.

Josh

---
  dir.c |    5 ++++-
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/dir.c b/dir.c
index 6e4494e..3f057b6 100644
--- a/dir.c
+++ b/dir.c

@@ -507,7 +507,10 @@ int excluded_from_list(const char *pathname,
              int to_exclude = x->to_exclude;

              if (x->flags & EXC_FLAG_MUSTBEDIR) {
-                if (*dtype == DT_UNKNOWN)
+                if (!prefixcmp(pathname, exclude) &&
+                    pathname[x->patternlen] == '/')
+                    return to_exclude;
+                else if (*dtype == DT_UNKNOWN)
                      *dtype = get_dtype(NULL, pathname, pathlen);
                  if (*dtype != DT_DIR)
                      continue;

-- 
1.7.6.msysgit.1

On Tue, Sep 20, 2011 at 8:03 AM, Joshua Jensen
[off-list ref] wrote:

Sometime after Git 1.7.3.2, sparse checkouts stopped working for me.  My
sparse-checkout file looks something like:

*
!DirA/
!DirB/
DirC/

I have restored some lines of code that were removed in November 2010.  This
resolves the sparse checkout issue for me, but my guess is the solution is
not implemented properly.

Can anyone confirm the issue

Confirmed. It got me wonder why the negated pattern tests did not
catch this. Turns out this works:

/*
!DirA/
!DirB/
DirC

This is my theory why yours does not work: negated patterns !DirA and
!DirB excludes both directories, but git still descends in them
because you may have other patterns that re-include parts of
DirA/DirB, for example:

DirA/DirD
!DirA

When it's in DirA/DirB, "*" tells git to match everything (equivalent
"DirA/*" and "DirB/*"), so it matches all entries in DirA/DirB again,
essentially reverting "!DirA" and "!DirB" effects.

By using "/*" instead of "*", we tell git to just match entries at top
level, not all levels.

I think it makes sense, but it's a bit tricky.

and describe why those lines were removed?

Quotes from 9e08273: "The commit provided a workaround for matching
directories in index. But it is no longer needed."
-- 
Duy

Joshua Jensen venit, vidit, dixit 20.09.2011 00:03:

That code was in git only between

c84de70 (excluded_1(): support exclude files in index, 2009-08-20)

and

9e08273 (Revert "excluded_1(): support exclude files in index", 2010-11-27)

i.e. after v1.6.4 and before v1.7.3.2

Ccing Duy who will know more.

Michael

----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 9/20/2011 4:09 AM

On Tue, Sep 20, 2011 at 8:03 AM, Joshua Jensen
[off-list ref]  wrote:

quoted

Sometime after Git 1.7.3.2, sparse checkouts stopped working for me.  My
sparse-checkout file looks something like:

*
!DirA/
!DirB/
DirC/

Confirmed. It got me wonder why the negated pattern tests did not
catch this. Turns out this works:

/*
!DirA/
!DirB/
DirC

This is my theory why yours does not work: negated patterns !DirA and
!DirB excludes both directories, but git still descends in them
because you may have other patterns that re-include parts of
DirA/DirB, for example:

DirA/DirD
!DirA

When it's in DirA/DirB, "*" tells git to match everything (equivalent
"DirA/*" and "DirB/*"), so it matches all entries in DirA/DirB again,
essentially reverting "!DirA" and "!DirB" effects.

By using "/*" instead of "*", we tell git to just match entries at top
level, not all levels.

I think it makes sense, but it's a bit tricky.

I can confirm this fix works for me, but it is certainly tricky.  IMO, 
it should either be documented or some kind of fix should be added to a 
future version of Git to allow * by itself to work again.

quoted

and describe why those lines were removed?

Quotes from 9e08273: "The commit provided a workaround for matching
directories in index. But it is no longer needed."

Yeah, I saw that, but it made little sense to me, especially since it 
seems to break a behavior that worked before.

Thanks!

Josh