Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)

> On 12/8/08, Daniel Barkalow <barkalow@iabervon.org> 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)

> >  > >  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.