patch, 3 partsTeach cat-file a --quiet option

Sometimes when you get the content of a file in a script you don't want an error message for missing files; instead its OK to treat a missing file the same as one whose content was empty.

This is especially true if the script is using something like `cat-file blob HEAD:path/to/file` to look at an optional file's content.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/git-cat-file.txt |    4 ++++
 builtin-cat-file.c             |   26 ++++++++++++++++++++------
 2 files changed, 24 insertions(+), 6 deletions(-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

I am not sure if I agree with this logic. How is this different from discarding stderr to /dev/null?

Junio C Hamano <junkio@cox.net> wrote:

...

 
Its not any different.  But it means I can do:

	open(I,'-|','git','cat-file','--quiet','blob',"HEAD:users/$who");

and not worry about redirection to silence the case of when $who is not in the users subtree of HEAD. Sure, I could redirect that, but then that's something more like:

	if (open(I,'-|')) {
		open STDERR, ">/dev/null";
		exec 'git','cat-file','--quiet','blob',"HEAD:users/$who";
		exit 1;
	}

and uh, why, that's really annoying. And my Perl is rusty enough that I'm not even sure I did that right, I'd have to go look it up danngit. And didn't we just add a --quiet to git-diff? This is different, but not that much different..

What's also annoying is cat-file today prints an error with -e if you use the "branch:path" syntax, but not if you supply the 40 byte hex SHA-1 of the blob in question. Again, you have to redirect the one syntax, but not the other, even for just a simple -e. Which makes -e slightly less useful. So I also fixed that...

Anyway... if you really don't like it, drop it, I'll just have to go digging through the Perl manual... ;-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

I _think_ the intent of -e or any other "silently check" option is to signal "status" with exit code, while still indicating an error with the message.

For the particular example of "cat-file -e", whose purpose is to accept an object name string and report if such an object exists in the repository:

	$ git cat-file -e 45354a57ee7e3e42c7137db6c94fa968c6babe8d; echo $?
        0
	$ git cat-file -e 45354a57ee7e3e42c7137db6c94fa968c6babe8e; echo $?
        1
	$ git cat-file -e HEAD:NO-SUCH-PATH
	fatal: Not a valid object name HEAD:NO-SUCH-PATH

The input of the above two _look_ like valid object names and they return Ok/Bad because the user is asking "is there such an object?".

Technically speaking, with the last case, the user did not give a correctly formatted object name (treeish colon needs to be followed by a path that exists in the treeish to be considered a valid object name), so it can be argued that complaining is the right thing to do, but that is too literal to the law and I would agree that it probably is on the wrong side of the borderline.

Junio C Hamano <junkio@cox.net> wrote:

Also, a redirect of stderr to /dev/null kills other error messages that might be interesting to see on stderr of the caller, like if a packfile isn't readable... while my --quiet patch doesn't.j The --quiet flag only kills errors that occurred because the requested object doesn't exist.

"Shawn O. Pearce" <spearce@spearce.org> writes:

I think that quite depends on what your definition of "other" is; see my other message on this subject.