Hi, On Mon, 17 Aug 2009, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Local changes in git do not belong to any particular branch. They > > belong to the work tree and the index. Hence you (1) can switch from > > branch A to branch B iff the branches do not have difference in the > > path with local changes, and (2) have to stash save, switch branches > > and then stash pop if you have local changes to paths that are > > different between branches you are switching between. > > > > How should assume-unchanged play with this philosophy? > > > > I'd say that assume-unchanged is a promise you make git that you won't > > change these paths, and in return to the promise git will give you > > faster response by not running lstat on them. Having changes in such > > paths is your problem and you deserve these chanegs to be lost. At > > least, that is the interpretation according to the original > > assume-unchanged semantics. > > Having said that, we could (re)define assume-unchanged to mean "I may or > may not have changes to these paths, but I do not mean to commit them, so > do not show them as modified when I ask you for diff. But the changes are > precious nevertheless" I am hesitant. The feature was introduced because of some report that Git was too slow. While the speed has increased dramatically (the report was for Windows), we cannot work miracles: the file system layer is just not cooperative. So I could imagine that redefining the meaning of assume-unchanged results in a substantially longer runtime again, which some people (yours truly) might interpret as regression. > I think the writeout codepath pays attention to assume-unchanged bit > already for that reason (CE_MATCH_IGNORE_VALID is all about this issue). If I were that reporter, I would not be happy, I guess. Basically, when new files come in and I marked all the files as "assume unchanged; I know what I'm doing!" Git would tell me "no you're an idiot, dummy, I know better, and I will check all over again!". > So with that, how should assume-unchanged play with the "local changes > belong to the index and the work tree"? > > - When adding to the index, the changes should be ignored; > > - When checking out of the index? I.e. the user tells "git checkout > path" when path is marked as assume-unchanged. Such an explicit > request should probably lose the local changes in the work tree. > > - When checking out of a commit? The same deal. > > - When switching branches? > > - If the branches do not touch assume-unchanged paths, we should keep > changes _and_ assume-unchanged bit. I do not know if that is what > the current code does. > > - If the branches do touch assume-unchanged paths, what should happen? > We shouldn't blindly overwrite the local changes, so at least we > should change the code to error out if we do not already do so. But > then what? How does the user deal with this? Perhaps... > > - Drop assume-unchanged temporarily; > - Stash save; > - Switch; > - Stash pop; > - Add assume-unchanged again. > > ??? In my book all this is overly complicated. If I tell Git to assume a file is unchanged, it is not Git's business to question me. > Is such an updated (or "corrected") assume-unchanged any different from a > sparse checkout? After all, paths that are not to be checked out in a > sparse checkout are "pretend that the lack of these paths are illusion--they > are logically there. I do not intend to commit their removal, and I do not > want to lose the sparseness across branch switch". > > There is one nit about this. If a path is outside the checkout area, > should it unconditionally stay outside the checkout area when you switch > branches? I may be interested in not checking out Documentation/ > subdirectory and that may hold true for all _my_ branches, and it is a > sane thing not to complain "Oops, you actually removed Makefile in > Documentation/ in your work tree in reality, and you are switching to > another branch that has a different Makefile --- it is a delete-modify > conflict you need to resolve, and we won't let you switch branches" in > such a case. > > But is that generally true in all "sparse checkout" settings? > > It is unfortunate that this message raises more questions than it answers, > but I think a sparse checkout will have to answer them, whether it uses a > bit separate from assume-unchanged or it reuses the assume-unchanged bit. I think you will come around and agree that the original, very simple therefore powerful, concept of "assume-unchanged" should be, well, unchanged, and not be bent to half-fit the original intention and half-fit the sparse intention. Rather, I agree with Nguyễn that the no-checkout bit (which is definitely free to behave differently from assume-unchanged) is needed. Maybe I contradict myself here with what I said after the third iteration of the sparse checkout series, but that only proves that I am able to learn. Ciao, Dscho