Thread (1 message) 1 message, 1 author, 2017-07-07

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

From: Junio C Hamano <hidden>
Date: 2017-07-07 17:58:07

Dan Fabulich [off-list ref] 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
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help