> From: Junio C Hamano [mailto:gitster@xxxxxxxxx] > Sent: Wednesday, September 13, 2017 4:18 PM > > Jacob Keller <jacob.keller@xxxxxxxxx> writes: > > > By definition if you do a sparse checkout, you're telling git "I only > > care about the files in this sparse checkout, and do not concern me > > with anything else"... So the proposed fix is "since git cleared the > > skip-worktree flag, we should actually also copy the file out again." > > but I think the real problem is that we're clearing skip worktree to > > begin with? > > As this 100% agree with what I've been saying, I do not have > anything to add to the discussion at the moment, so I'll stop > speaking now but will continue to monitor the thread so that I may > hear a new argument and datapoint that would make me change my mind. > > Thanks for a healthy discussion. Hi Junio, Thanks for the feedback. I will give this implementation a try. I still have the following unanswered questions, if you wouldn't mind answering. 1. Does this statement, "I only care about the files in this sparse checkout, and do not concern me with anything else", mean that git should not change files outside the sparse-checkout whether that be in the working directory or in the index? Or does that only apply to the working directory and the index version of files can change to whatever git the git command would do without using sparse? For example if I am doing a 'git reset HEAD~1' should the version in the index of files outside the sparse not be changed or change to the HEAD~1 version with the skip-worktree bit on? 2. How will this work with other git commands like merge, rebase, cherry-pick, etc.? 3. What about when there is a merge conflict with a file that is outside the sparse checkout? Should there not be a conflict because git shouldn't be trying to merge the file since it is outside the sparse checkout area? Should the conflicted file get written outside the sparse checkout so the user can resolve it? Thanks, Kevin
