David Aguilar <davvid@xxxxxxxxx> writes: > On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote: >> >> 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. > > Git has always been really careful to not lose data. > > One way to avoid the problem of changing existing semantics is > to make the new semantics accessible behind a flag, e.g. > "git checkout --hard HEAD -- some-new-path". Yup, but you seem to be behind by a few exchanges, as we tentatively decided that we won't talk about changing the semantics and concentrate on fixing the implementation glitches only at least for now ;-) I find that "--hard" is not a very good name for the new mode. There will be different kinds of "more than what we usually do" modes of operations discovered over time in the coming years, and it is better to be more specific to denote "in what way we are doing it harder" (I think the difference the proposed new mode has is to also checkout absense of the paths). But in this particular case, making the paths that are absent in $tree we are checking out of into untracked paths (instead of removing) is a right balance of safety---it is similar to "git reset HEAD" (no "--hard") after adding a new path which leaves the file in the working tree. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html