Why does git-checkout accept a tree-ish?

From: Dan Fabulich <dan@fabulich.com>
Date: Apr 5, 2017, 23:51 UTC
Message-ID: <EA993AC0-022C-423D-ABD7-4747FA09E7FE@fabulich.com>

I was looking back through git's history, trying to figure out why git-checkout has so many features. I was struck by this commit by Junio in 2005.

https://github.com/git/git/commit/4aaa702794447d9b281dd22fe532fd61e02434e1

Show 6 quoted lines

> git-checkout: revert specific paths to either index or a given tree-ish.
> When extra paths arguments are given, git-checkout reverts only those
> paths to either the version recorded in the index or the version
> recorded in the given tree-ish.
> 
> This has been on the TODO list for quite a while.

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.)

I think the "UNIX philosophy" would have advocated that a new command be created to handle this case, perhaps something like git-checkout-tree. (That would also have eliminated the need to use -- to disambiguate the tree-ish from the paths.)

And so I wonder if anybody knows just why git-checkout gained these two features in one commit, without creating a separate command.

I have two guesses:

1) It was pretty easy for Junio to implement as part of git-checkout; just 20 lines of code and a small test.

2) git at the time was distributed as a collection of files, git-checkout, git-reset, etc. and so there was some pressure not to create a new command for fear that it would clutter the filesystem.

Are those the actual reasons? (This seems like it might be a FAQ, but Google failed me searching for git faqs or "why does git checkout do so many things.")

-Dan

P.S. I would make a similar argument about adding <paths> support to git-reset, rather than creating a separate command like git-unadd.

https://github.com/git/git/commit/2ce633b928f78224a37308f45810e76fefe8df56 It was documented a couple of weeks later on Dec 26. https://github.com/git/git/commit/6934dec89538e054823aadcce08af040bc8dcf79