git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Dan Fabulich <dan@fabulich.com>
To: git@vger.kernel.org
Subject: Why does git-checkout accept a tree-ish?
Date: Wed, 5 Apr 2017 16:51:40 -0700	[thread overview]
Message-ID: <EA993AC0-022C-423D-ABD7-4747FA09E7FE@fabulich.com> (raw)

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

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

             reply	other threads:[~2017-04-05 23:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 23:51 Dan Fabulich [this message]
2017-07-07 17:57 ` Why does git-checkout accept a tree-ish? Junio C Hamano
2017-07-07 19:59 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EA993AC0-022C-423D-ABD7-4747FA09E7FE@fabulich.com \
    --to=dan@fabulich.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).