On Wed, Aug 8, 2012 at 5:31 AM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > Thomas and me -- it was mostly my bad idea -- spent some time going > through all the loops that iterate over the index. You can get some > taste of it with 'git grep ce_stage', mostly because many of them either > skip unmerged entries or specifically look for them. There are subtle > differences between the loops on many points: what do they do when they > hit an unmerged entry? Most of them ignore unmerged entries, git-add and git-update-index can remove unmerged entries, unpack-trees (reset, merge, checkout...) can generate them. What's the problem with it? > Or a CE_REMOVED or CE_VALID one? CE_VALID is assume-unchanged feature. I don't think we have problems with it. CE_REMOVED is to say "we are going to remove this entry both in index and worktree, but if we remove it now we would have no way to know which file in worktree to be removed later on, so we just mark it here as a ghost entry in index". It's only used by unpack-trees, I think. >From the index pov, CE_REMOVED entries never get written to file. It may complicate tree building for v5. -- 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