Hi, There is a problem with those things and I don't know how to handle it. In brief, in "git reset --hard" (or "git read-tree --reset"), unmerged entries will be removed from in-memory index, so merge process does not see them and re-add them like new entries. But with sparse checkout, "new entries" and "merged entries" are handled differently. This may lead to stale/orphaned entries. The detail: 1. unmerged entries are filtered out from cmd_read_tree() if --reset is provided. 2. inside unpack_trees(), [1-3]way_merge() pass src[0] (which is NULL in unmerged cases) to merged_entry() 3. merged_entry() sees it as "no old entry so this must be new entry", it makes sure there is no real file in working directory, but then the check is ignored in --reset mode. 4. entries get added as new ones. With sparse checkout, in the last two steps, it would check if new entry matches default sparse pattern (which determines if the entry should be added to working directory). In case it decides the entry should not be added to working directory, it would remove CE_UPDATE flag from the entry. This is fine for _true_ new entries. But in unmerged case, it would leave a stale/orphaned entry in working directory while it is marked no-checkout in index. I would expect sparse checkout work correctly even in unmerged case. That is the entry is removed from working directory (if outside sparse pattern), staged entries are removed in index, stage 0 entry is added with no-checkout flag. Comments? Maybe doing a two-phase merge (unmerged entries first, the rest later)? -- 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
