First of all, thanks again for spending time on this. On Sat, Nov 8, 2014 at 12:30 AM, Jeff King <p...@peff.net> wrote: > On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote: > > 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).
Yes, I think that's what I would expect. > 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. I don't think we'd want it to be deleted. I would view 'git reset --hard' as the role model here, and that command (without paths) would not remove the file. And applying it to a path should not change the behavior, just restrict it to the paths, right? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
