On 12/8/08, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > This was discussed since the beginning of this feature. I recall that > > the index reflects worktree, and because we mark CE_NO_CHECKOUT on > > file basis, it's best to save the information there, not separately. > > We do save high level information to form the checkout area (sparse > > patterns) in the last half, but basically you should be able to live > > without that. > > > We need to mark in the index the information that reflects the worktree. > > If, however, we take CE_VALID to be the flag for "ignore the worktree > entirely at this path; act as it if contains what the index contains" (and > use this to cause that aspect of no-checkout), and we then entirely ignore > the worktree, including not caring whether there are files there or not > (except, of course, that in the transition from caring to not caring for > no-checkout, we make the worktree empty, while in the case for > "stat-is-expensive", we bring it into agreement with the index), then > there is no additional information that needs to be conveyed in the index. That's not enough. CE_VALID is "ignore the worktree files" while CE_NO_CHECKOUT is stricter: "those files does (or should) not exist". The difference is - for "git grep", we ignore path with CE_NO_CHECKOUT (while using cache version for CE_VALID) - porcelain-level support to widen/narrow checkout area will need CE_NO_CHECKOUT, not CE_VALID > > > > unless it's ever important to remember whether an entry is CE_VALID due to > > > having been outside the checkout when the index was written, even though > > > the checkout area now includes it. I don't have a good intuition as to > > > what ought to happen if the user manually changes what's specified for > > > checkout without actually updating the index and working tree. > > > > So if a user changes worktree without updating index, they will have > > the same results as they do now: files are shown as modified if they > > don't have CE_NO_CHECKOUT set. If those files do, they are considered > > 'orphaned' or staled and are recommended to be removed/updated to > > avoid unexpected consequences (not availble this this first half > > series because that belongs to "git status"). > > > I was actually thinking that there would be a file for "this is what the > user wants to have checked out" (as opposed to the index, which must > contain "this is what is checked out"), and the porcelain would instruct > the plumbing as to what to do with the worktree (that the plumbing with > then ignore, due to the index bit) based on this information. > > The index obviously can't contain the user's full instructions for what > should be checked out, because the user will want to say "I don't care > about anything in Documentation/" and have this apply to > Documentation/some-file-not-in-the-index, so that if this file is in the > worktree, the user gets a warning. > > I think you're doing this with core.defaultsparse, although you seem to > allow the index to diverge from this easily. Yes they can. > > The question, then, is what happens when the index and core.defaultsparse > disagree, either because the porcelain supports causing it or because the > user has simply editting the config file or used plumbing to modify the > index. That is, (1) we have index entries that say that the worktree is > ignored, and the rules don't say they're outside the sparse checkout; do > we care whether we expect the worktree to be empty or match the index? > And, (2) we have index entries that say we do care about them, but the > rules say they're outside the sparse checkout; what happens with these? The rule is CE_NO_CHECKOUT is king. core.defaultsparse only helps setting CE_NO_CHECKOUT on new entries when they enter the index. So if core.defaultsparse does not match what is in index, that's fine. You may get more files with "git merge", "git checkout".. but already-removed files should stay removed. If you are not happy with core.defaultsparse, you can replace it with your own tools by manipulating directly CE_NO_CHECKOUT using "git update-index" and "git ls-files". BTW the implementation has not had an easy way to replace core.defaultsparse. You have to modify apply_narrow_spec(). But if someone really needs it, a hook can be added. -- Duy -- 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
