Hi, On Mon, 17 Aug 2009, skillzero@xxxxxxxxx wrote: > On Mon, Aug 17, 2009 at 3:02 PM, Johannes > Schindelin<Johannes.Schindelin@xxxxxx> wrote: > > > And here comes the problem: if something is treated untracked because > > it was outside of the sparse checkout, then I want it to be treated as > > untracked _even if_ I happened to broaden the checkout by editing > > .git/info/sparse. The file did not just magically become subject to > > overwriting just because I edited .git/info/sparse (which could be a > > simple mistake). > > Maybe I'm misunderstanding what you're saying, but why would you want a > file that's become part of the checkout by editing .git/info/sparse to > still be treated as untracked? > > If I have a file on that's excluded via .git/info/sparse then I edit > .git/info/sparse to include it and switch to a branch that doesn't have > that file, I'd expect that file to be deleted from the working copy if > the content matches what's in the repository. If it's modified then I'd > expect the branch switch to fail (like it would without a sparse > checkout). First things first: with sparse checkout, you should not check out _anything_ outside of the focus of the sparse checkout. So I contend that you would only end up with a sparse'd-out file that was formerly tracked if you did something wrong. That should not happen. Even if: all the more reason to have a flag that indicated that this file is not sparsed'd-out -- contradicting .git/info/sparse. The thing is: we need a way to determine quickly and without any ambiguity whether a file is tracked, assumed unchanged, or sparse'd-out (which Nguyễn calls no-checkout). And if we change .git/info/sparse, that state _must not_ change. We did not touch the file by editing .git/info/sparse, so the state must be unchanged. Whether "git checkout" should realize that a checked out file (which has no changes, mind you!) needs to be deleted and marked no-checkout is a different question. Ciao, Dscho