Re: Why does git-checkout accept a tree-ish?

[Junio C Hamano <gitster@pobox.com>]

Dan Fabulich <dan@fabulich.com> writes:

> Prior to this commit, git-checkout would only switch branches; you
> could use git-checkout-index to copy files from the index to the
> working tree. But in this commit, git-checkout not only subsumes
> the functionality of git-checkout-index but also learns the
> ability to copy files from an arbitrary branch (now an arbitrary
> tree-ish) into the working copy *and* the the index. (That was
> important because git-reset didn't accept <paths> in 2005.)
> ...
> P.S. I would make a similar argument about adding <paths> support
> to git-reset, rather than creating a separate command like
> git-unadd.

I do not have a habit of crying over spilt milk for too long, but if
we did not have "git reset <paths>..." and adding an equivalent
feature today, I would guess that we would not have done it as a
different mode for "git reset".  We probably wouldn't have added an
extra command "unadd", either.

"git checkout --cached [<tree-ish>] <paths>..." would have been more
in line with the CLI convention for a command that can act on the
index and/or the working tree files ("--cached" is the way to make a
request to act only on the index without affecting the working tree
files).

As to why "git checkout" started taking <paths>, the thread referred
to in my previous response seems to give a better story than I could
remember ;-).  We were unhappy with checkout-index and the
suggestion that was first made publicly reused "git checkout".
While I initially showed my reluctance by calling the hypothetical
command "xxxxxx" instead of Linus's suggested overloading of
"checkout" in my response in the thread, I think the end-result
turned out to be not too bad, given that our users understand the
difference between 

 - checking out a branch to work on advancing the history of the
   branch; and

 - checking out a set of paths out of a <tree-ish> to modify the
   working tree contents while working on advancing the history of
   the current branch.

just fine.  When doing the former, you would of course want to
preserve local modifications in your working tree.  When doing the
latter, you are asking to overwrite the named paths (checking them
out of a tree-ish or the index is often done to wipe the mistaken
attempt to modify it and giving you a clean slate).