[RFD] Sparse checkout, unmerged entries and "reset --hard"

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:45:28

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help