On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote: > > Hrm. Probably not. It is almost a one-way merge going to the named tree > > (but limited by the pathspec), except that I think the current > > git-checkout code may provide some safety checks related to where we are > > coming from (e.g., do we unconditionally overwrite entries that are not > > uptodate?). > > I think we do unconditionally overwrite and that has been very much > on purpose. I thought so, too, but I was thrown off by the code in checkout_paths() that warns/aborts if there are unmerged entries. But it looks like we will have thrown out those entries already during the read_tree_some call, which adds the new entries using OK_TO_REPLACE. > "git checkout tree-ish -- file.txt" has always been about replacing > whatever cruft is in paths in the worktree that match pathspec, just > like "cat content-created-elsewhere >file.txt" is. "Oops, you have > a local change that do not match index" is the last thing we want to > say, because getting rid of that local change is the primary reason > why "checkout tree-ish -- file.txt" exists. > > Taking the state of a subdirectory as a whole as "content", the > change we are discussing will make it more like "rm -fr dir && tar > xf some-content dir" to replace the directory wholesale, which I > personally think is a good thing in the longer term. Yeah, that makes sense. What about untracked files? Right now we overwrite them if the tree-ish has an entry at the same path; that is a bit more dangerous than the rest of git, but does match the "ignore local modifications" rule. I assume if we handled deletions, though, that we would simply leave them be. So given that, is it fair to say that a one-way "go here" merge, limited by pathspec, is the closest equivalent? -Peff -- 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