Too Many Directories In Working Copy After Git Sparse Checkout

Question

We have a git repo (remote is hosted at github - lets call it the Clients repo) with 210+ directories in the root. We have 210+ windows servers that each need one of those root directories, and don't really need the others.

So we log into one of the servers, and using 1.8.1.msysgit.1

1. Clone the Clients repo from git hub
2. Turn on sparse checkouts
3. Update the sparse-checkout file with the single *directory/* that we want in this servers working copy
4. Perform our read-tree operation

and 9 times out of 10 everything just works, and out working copy contains the single directory we expect.

However, every once in a while, it will not work as expected and we will get a handful of other directories bleeding through to the working copy as well. It has never been the full 210+, but will be between 6-10 other directories. Those directories do not match the pattern of the desired directory, nor to they have any subdirectories that match said pattern.

We have never been able to resolve the local repo once this happens. We have tried:

• Various resets
• Various read-trees
• Disable/Re-enable sparse-checkout
• Inspect log to see if anything weird happened

Ultimately, we typically end up deleting the local repo, following the same steps again, and it just works the second time.

We have yet to find a way to reliably reproduce the problem, aside from cloning, setting up sparse checkouts, etc. repeatedly. Of the 20 or so times this has happened, it has only happened once on a non-windows machine (we had an ubuntu server running git v1.8.1.5 that displayed the same issue two weeks ago).

My Google-Fu is weak in this. I would appreciate any insight into why this is happening, and any potential workarounds that don't have us deleting a repo and re-cloning it. Thanks in advance!

Answer 1

I had friend once who ran into exactly this problem. It turned out to be that they had removed files from child directories on a Unix system, then when they did their git reset on Windows systems, it would remove all the files from the (now) empty directories, but would not remove the directories themselves since Git only tracks content, not directories.

Is the "larger" subset of folders on a Windows system? Are those directories empty? Therein might lie your problem.

Answer 2

Windows is wonky with it's permissions. The folders may have been left over after sparse checkout cleaned it up, may need to go in and manually delete them. They're probably empty ;)