[RFC] 'git cat-file' needs a better design on its option interface

[Li Hong <lihong.hi@gmail.com>]

Hi All,

When using 'git cat-file' recently, I find its option interface is somewhat
inconvenient or mistakenly-designed.

	1. There is no default action. You have to use -p or <type> option,
	even for a simple look at the content of an object. It is better if
	we can provide a default action just like 'cat' does.
	
	2. Can't control the output. Several output options can't be used at
	the same time. Can't control what to output and how to output. I
	suggest here we use a simple format string to let the human being
	and other batch scripts happy.

	3. Batch mode is handled seperately and differently.

	4. <type> option has a mix meaning (raw print and object dereference)
	and is also inconsistent with -x style option.

	  * for raw print, an format char such as 'r' should be a good choice.
	  * for dereference, should use the uniform rev-naming. (e.g.
	    v0.99.8^{commit})


So I propose to amend the interface as follow:

	git cat-file [-b] [-f <fmt>] [-e] <args> ...

	-b	read more objects from stdin
	-f	provide a output format string
	-e	silent, exit with zero when there's no error

	the default action is to pretty-print the content when there is no
	other options except -b.

A format string example can be formed as follow (this needs more discuss):

	"blabla %t\s%s\t%h\n%p\n%r\n\n"

	%t: type
	%s: size
	%h: sha1
	%p: pretty-print
	%r: raw-print

However, this change will give a heavy impact on many documents and scripts
depending on this command. There are 233 references in source code according
to a trivial count 'grep -r "cat-file" * | wc -l', not to mention many
private usage of this command.

So this is just a RFC. If I can get a very positive feedback from the
community, I may start to do the real code change.

Any ideas?

- Li Hong