Duy Nguyen <pclouds@xxxxxxxxx> writes: >>> How about this: >>> >>> git-checkout - Switch branches or restore changes to the working tree >> >> Gahh. We are NOT restoring CHANGES. We are restoring the whole >> contents to a path. > > "the whole contents" is only true when --patch is not used, I think. I've seen that people repeat this "patch is not the whole" and have ignored that comment; you really need to think if that nitpick adds anything of value to the description before repeating it. The "patch" interface of course allows you to pick and choose. You have some contents (call it W) in the working tree. You have different contents (call it X) somewhere else. Being able to do that is the whole point of the feature. But what is presented you as the choice to pick or ignore? It is the difference between W and X. If you take none from what is offered, you won't check out anything. If you take all of them, you check out the whole of X. The result is somewhere in between. An important point that everybody who repeats "patch is not the whole" seems to be missing is that it will never be somewhere between W and Y (the latter of which is different from X). Now, what is the X in this operation? It is either what is registered in the index, or in the tree-ish specified on the command line. So I'd say that the right mental model to understand the "--patch" feature is that it allows you to check out the whole contents from elsewhere; after the command line argument selects from where, i.e. either from the index or from a tree-ish, you _additionally_ have a choice to pick which part of that whole to use. The diff between W and HEAD or W and index, i.e. "CHANGES", does not play any part of this selection process. -- 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