On Mon, 8 Dec 2008, Nguyen Thai Ngoc Duy wrote: > 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) Is this sufficient? I'd expect "git grep" to ignore paths that are outside the checked-out region, even when searching an arbitrary tree, and even when those files aren't in the index at all (i.e., the current commit doesn't have them). That is, I'd expect core.defaultsparse or the equivalent to limit the paths, normally giving this effect. > - porcelain-level support to widen/narrow checkout area will need > CE_NO_CHECKOUT, not CE_VALID This isn't a meaningful difference between CE_NO_CHECKOUT and CE_VALID if there aren't any other differences. > > > > 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. This seems like a really bad idea to me. If you ask for a file that's outside your default area to be checked out, and then you switch branches and switch back, the file may or may not disappear (depending on whether the branch you switched to temporarily had it or not). Likewise, if you remove files, and then switch branches and back, the files may or may not reappear. Of course, commands need to look at the index to determine what we've actually done with the worktree and index, but I think there should be some other location that is responsible for keeping track of what the user has asked for. -Daniel *This .sig left intentionally blank* -- 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
