Hi, On Mon, 17 Aug 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > However, my illustration of the scenario was only to one end, namely > > to convince all of you that assume-changed != sparse. > > > > And maybe to the end to explain that sparse checkout could help this > > guy. > > How? If sparse is _not to check it out_, then that is not what the > person is doing either. It feels to me that you are suggesting an > inappropriate hack to replace another inappropriate hack, suggesting to > use a hacksaw because an earlier attempt to use a hammer did not quite > work to drive the screw in. Not exactly. What does "sparse checkout" mean, really? It means that Git should only check out a part of the tracked files, and not even so much as look outside. It means to me that everything outside of that focus is clearly to be handled as all the other untracked data. 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). So the index _needs_ to know that the sparse'd-out attribute is something completely different from the assume-unchanged attribute, even if Git should _handle_ the files with those attributes pretty similar _most_ of the time. > I never said assume-unchanged _is_ sparse. You cannot mark an index > entry that does not exist, obviously you need more (either the earlier > "hook that tells what should/shouldn't exist", or "the pattern"). Right. > But I think the work-tree semantics you need to _implement_ sparse > matches what you would want from assume-unchanged. Not the original, > draconian one that updates the work tree by saying "you promised me you > wouldn't change them", but the updated one that tells git to pretend > that the local change is not there but still keep the local > modification, including deletion. The work-tree "local changes" sparse > makes is a small subset of possible local changes assume-unchanged would > need to support. It only deletes work tree files. As I tried to convince you already, it is not wise to mix up the two meanings. They _are_ different: in one case, we _have_ a file, and we even _expect_ the file to actually have the same contents as what is recorded in the index. In the other case, we do _not_ have a file, so we do _not_ even expect the file to have the same contents. In fact, in the latter case (the sparse case) we do not want to look for the file; not for the reason that we expect the contents to be the same anyway, but because we expect it not even to be there! So while the _technical_ side is pretty much the same (most of the time, I illustrated a corner case, it it is very easy to think of other corner cases that might even be inadvertent, all the more reason to protect the user) -- don't look for the file -- the _semantics_ are _very_ different. And you see that they are different when all of a sudden you cannot take the _absence_ of the file as the indicator for "assume-unchanged" and "sparse". In fact, with the semantics implied by the label 'assume-unchanged', it could well be argued that making the file _absent_ (for the sparse checkout) is a dirty trick. This is not what "assume that the file is unchanged" implies at all. So let's just keep the semantics utterly simple and stupid, and have an - assumed-unchanged bit, which assumes that a file is there, but that the contents need not to be checked for performance reasons, and - a no-checkout bit, which assumes that the user never checked out that file (if it exists, it comes from somewhere else, and needs to be protected like untracked files that would be overwritten by a branch switch). I hope this explanation was clear. Ciao, 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