On Sat, Dec 1, 2012 at 1:24 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes: > >> On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk >> <martinvonz@xxxxxxxxx> wrote: >>> Slightly off topic, but another difference (or somehow another aspect >>> of the same difference?) that has tripped me up a few times is that >>> "git checkout $rev ." only affects added and modified files... > > "checkout $commit pathspec" has always been about ... I suppose the "has always been" is meant to say that it's hard to change at this point, not that it's more intuitive the way it works..? > ...checking out the > contents stored in the paths that match the pathspec from the named > commit to the index and also o the working tree. I think I have always thought that "git checkout $commit $pathspec" would replace the section(s) of the tree defined by $pathspec. (I'm using "tree" in the more general sense here, as I'm understood the index is not stored as a tree.) > When pathspec is "dir/", it does not match the directory whose name > is "dir". The pathspec matches the paths that store blobs under > that directory. Ah, right. Unlike "git reset dir/", IIUC. More importantly, when is it desirable not to delete deleted entries? I find it much easier to imagine uses a "git checkout $commit $pathspec" that does delete deleted entries. It seems like this must have been discussed in depth before, so feel free to point me to an old thread. If it doesn't seem too strange to you and others if I make "git reset --hard [$commit] $pathspec" work just like had expected "git checkout $commit $pathspec", I might look into that when I get some time. > ...The "please > remove everything in dir/" part is not the job of "checkout"; of > course, you can do it as a separate step (e.g. "rm -fr dir/"). "rm -rf dir/" would of course delete everything in there, including e.g. build artifacts.... -- 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