Re: [RFC] git checkout $tree -- $path always rewrites files

On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:

Thanks for that link.

I did spend a few hours on this topic earlier today, and got very confused trying to figure out what the deletion behavior _should_ be, and whether I was breaking it. For some reason I had zero recollection of a conversation from last year that I was obviously a major part of. I think I am getting old. :)

The end of that thread concludes that a diff-based approach is not going to work, because we need to update the working tree even for files not mentioned by the diff. I do not think that is a show-stopper, though. It just means that we need to load the new index as one step (done now with read_tree_recursive, but ideally using diff), and then walk over the whole resulting index applying our pathspec again (instead of relying on CE_UPDATE flags).

This turns out not to be a big deal, because the existing code is already doing most of that second pathspec application anyway. It does it because read_tree_recursive is not smart enough to update the "seen" bits for the pathspec. But now we would have another reason to do it this way. :)

So just to be clear, the behavior we want is that:

  echo foo >some-new-path
  git add some-new-path
  git checkout HEAD -- .

will delete some-new-path (whereas the current code turns it into an untracked file). What should:

  git checkout HEAD -- some-new-path

do in that case? With the current code, it actually barfs, complaining that nothing matched some-new-path (because it is not part of HEAD, and therefore we don't consider it at all), and aborts the whole operation. I think we would want to delete some-new-path in that case, too.

-Peff