[RFC] 'git cat-file' needs a better design on its option interface
- From
- Li Hong <lihong.hi@gmail.com>
- Date
- Sep 24, 2009, 15:04 UTC
- Message-ID
- <3a3680030909240804w1399ed7fhd6367300544f34f@mail.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