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

> Jeff King <peff@peff.net> writes:
> 
> > 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).
> 
> With the updated semantics proposed in the old thread, yes, that is
> what should happen.
> 
> >   git checkout HEAD -- some-new-path
> >
> > do in that case?
> 
> Likewise.  And if some-new-path were a directory, with existing path
> O and new path N both in the index but only the former in HEAD, the
> operation would revert some-new-path/O to that of HEAD and remove
> some-new-path/N.  That is the only logical thing we could do if we
> were to take the updated sematics.
> 
> That is one of the reasons why I am not 100% convinced that the
> proposed updated semantics is better, even though I was fairly
> positive in the old discussion and also I kept the topic in the
> "leftover bits" list.  The above command is a fairly common way to
> say "I started refactoring the existing path some-path/O and
> sprinkled its original contents spread into new files A, B and C in
> the same directory.  Now I no longer have O in the working tree, but
> let me double check by grabbing it out of the state recoded in the
> commit".  You expect that "git checkout HEAD -- some-path" would not
> lose A, B or C, knowing "some-path" only had O.  That expectation
> would even be stronger if you are used to the current semantics, but
> that is something we could fix, if we decide that the proposed
> updated semantics is better, with a careful transition plan.
> 
> It might be less risky if the updated semantics were to make the
> paths that are originally in the index but not in $tree untracked
> (as opposed to "reset --hard" emulation where they will be lost)
> unless they need to be removed to make room for D/F conflict issues,
> but I haven't thought it through.