> -----Original Message----- > From: Duy Nguyen [mailto:pclouds@xxxxxxxxx] > Sent: Monday, April 10, 2017 4:24 AM > To: Kevin Willford <kcwillford@xxxxxxxxx> > Cc: git@xxxxxxxxxxxxxxx; gitster@xxxxxxxxx; peff@xxxxxxxx; Kevin Willford > <kewillf@xxxxxxxxxxxxx> > Subject: Re: [PATCH 3/3] reset.c: update files when using sparse to avoid > data loss. > > On Fri, Apr 07, 2017 at 12:23:57PM -0700, Kevin Willford wrote: > > When using the sparse checkout feature the git reset command will add > > "git reset" has three different modes. It would be good if you mention what > mode is affected here. The tests are for --mixed only. I wonder if we need to > do anything for --hard and --soft? > > --soft touches branch SHA-1 index only, not worktree, so probably not. > > --hard should be handled by unpack_trees(), I think. > > But it would be good to cover these in the commit message as well to stop > readers from wondering. Sounds good. > > > entries to the index that will have the skip-worktree bit off but will > > leave the working directory empty. File data is lost because the > > index version of the files has been changed but there is nothing that > > is in the working directory. This will cause the next status call to > > show either deleted for files modified or deleting or nothing for files > added. > > The added files should be shown as untracked and modified files should > > be shown as modified. > > Hmm.. reading --mixed documentation again ("Resets the index but not > working tree"), I think the current behavior is expected regardless of skip- > worktree bits. > > Perhaps the problem is the loss of skip-worktree bits on entries added by > update_index_from_diff()? If the bits are at the right place, then it should > not matter if the same version exists on worktree or not and "status" or > "commit" should work as expected, I think. > > -- > Duy 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. 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. Kevin