On Wed, Apr 12, 2017 at 5:30 AM, Kevin Willford <kewillf@xxxxxxxxxxxxx> wrote: > The loss of the skip-worktree bits is part of the problem if you are talking > about modified files. The other issue that I was having is when running a reset > and there were files added in the commit that is being reset, there will not > be an entry in the index and not a file on disk so the data for that file is > completely lost at that point. "status" also doesn't include anything about > this loss of data. On modified files status will at least have the file as deleted > since there is still an index entry but again the previous version of the file > and it's data is lost. Well, we could have "deleted" index entries, those marked with CE_REMOVE. They are never written down to file though, so 'status' won't benefit from that. Hopefully we can restore the file before the index file is written down and we really lose skip-worktree bits? > To me this is totally unexpected behavior, for example if I am on a commit > where there are only files that where added and run a reset HEAD~1 and > then a status, it will show a clean working directory. Regardless of > skip-worktree bits the user needs to have the data in the working directory > after the reset or data is lost which is always bad. I agree we no longer have a place to save the skip-worktree bit, we have to restore the state back as if skip-worktree bit does not exist. It would be good if we could keep the logic in unpack_trees() though. For example, if the file is present on disk even if skip-worktree bit is on, unpack_trees() would abort instead of silently overwriting it. This is a difference between skip-worktree and assume-unchanged bits. If you do explicit checkout_entry() you might have to add more checks to keep behavior consistent. -- Duy