From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 07 Jul 2017 17:57:56 GMT
Subject: Re: Why does git-checkout accept a tree-ish?
Message-ID: <xmqqshi8b04b.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <EA993AC0-022C-423D-ABD7-4747FA09E7FE@fabulich.com>

Dan Fabulich <dan@fabulich.com> writes:

> 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
>
>> 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.)
> ...
> And so I wonder if anybody knows just why git-checkout gained
> these two features in one commit, without creating a separate
> command.

The whole thread would explain it, I think.

https://public-inbox.org/git/Pine.LNX.4.64.0510171814430.3369@g5.osdl.org/#t