From: Junio C Hamano Date: Thu, 14 Dec 2006 06:29:14 GMT Subject: Re: What's in git.git (stable) Message-ID: <7vy7pb9eit.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Nicolas Pitre writes: > On Thu, 14 Dec 2006, Johannes Schindelin wrote: > >> I sent a patch which makes "git show" have that functionality, and >> frankly, I disagree "less" would be a good name for it. It uses the >> _pager_, which is not always "less", and besides, what it does is to show >> that particular blob. So obviously, I think my patch is the best approach. > > I think your approach is pretty sensible too. I think so too for a few reasons. * cat-file is a very low level plumbing. Giving it -p was a mistake made by somebody lazy long time ago back when we were not all that hot about "user friendliness in Porcelain-ish" (the option -p was not originally even meant to be the user level; it was merely a helper feature for verify-tag). * If we were to call something 'cat' and make a user-level command, adding the feature to 'show' is a lot more sensible than cat-file; the former takes more than one args already. People expect 'cat' to concatenate the arguments. cat-file doesn't. * Throwing ls-tree output is the most sensible thing to do at 'cat-file -p ' level, but not at the UI level (Andy compared ls-tree with 'svn list' today). With 'git show', it would be more natural to show ls-tree --name-only by default for tree-ish objects, and control the verbosity level with command line option. One minor issue we may need to decide is what to do when show is given a tag object. Personally I think the current behaviour of dereferencing it to commit is fine (people who want to see the tag can always do 'git-verify-tag -v').