[SOLVED] git-cat-file output

I am not sure git cat-file --batch is supposed to work the way you mention in your question.
(It might after git 2.8, March 2016, see below)

Even in the "GitMagic book", in an unix environment, the git cat-file is used like sinelaw mentions in the comments:

Check this ﬁle does indeed contain the above by typing:
$ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch

As the OP Alex.Shen mentions above, this is an newline issue:
git commands will alway expects LF ^{(Line Feed, U+000A)}, not the Windows CRLF ^{(CR+LF: CR (U+000D) followed by LF (U+000A))} sequence.
With the '|', it uses the EOL character of the bash msysgit shell (LF), so it always works.

Note: Git 2.5+ (Q2 2015) will add support for symlinks with git cat-file --batch.
(New Git releases are available for windows at github.com/git-for-windows/git/releases)

See commit 122d534 by David Turner (csusbdt), 20 May 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit 67f0b6f, 01 Jun 2015)}

cat-file: add --follow-symlinks to --batch

"git cat-file --batch(-check)" learned the "--follow-symlinks" option that follows an in-tree symbolic link when asked about an object via extended SHA-1 syntax.

E.g. HEAD:RelNotes that points at Documentation/RelNotes/2.5.0.txt.

With the new option, the command behaves as if HEAD:Documentation/RelNotes/2.5.0.txt was given as input instead.

Update February 2016:

Git 2.8 add support for CRLF to some git commands:

See commit a551843, commit 933bea9, commit 1536dd9, commit b42ca3d, commit 692dfdf, commit 3f16396, commit 18814d0, commit 1f3b1ef, commit 72e37b6, commit 6e8d46f, commit c0353c7 (28 Oct 2015) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 0175655, 03 Feb 2016)}

In particular, commit b42ca3d uses strbuf.c#strbuf_getline() (which can take a byte other than LF or NUL as the line terminator)

With git 2.8:

cat-file: read batch stream with strbuf_getline()

It is possible to prepare a text file with a DOS editor and feed it as a batch command stream to the command.

Note that before Git 2.33 (Q3 2021), "git cat-file --batch-all-objects"^(man) misbehaved when --batch is in use and did not ask for certain object traits.

See commit ee02ac6, commit e16acc8 (03 Jun 2021) by ZheNing Hu (adlternative).
^{(Merged by Junio C Hamano -- gitster -- in commit 5d96bcb, 13 Jul 2021)}

cat-file: handle trivial --batch format with --batch-all-objects

^{Helped-by: Jeff King}
^{Signed-off-by: ZheNing Hu}
^{Acked-by: Jeff King}

The --batch code to print an object assumes we found out the type of the object from calling oid_object_info_extended().
This is true for the default format, but even in a custom format, we manually modify the object_info struct to ask for the type.

This assumption was broken by 845de33 (cat-file: avoid noop calls to sha1_object_info_extended, 2016-05-18, Git v2.9.0-rc1 -- merge) (cat-file: avoid noop calls to sha1_object_info_extended, 2016-05-18).
That commit skips the call to oid_object_info_extended() entirely when --batch-all-objects is in use, and the custom format does not include any placeholders that require calling it.

Or when the custom format only include placeholders like %(objectname) or %(rest), oid_object_info_extended() will not get the type of the object.

This results in an error when we try to confirm that the type didn't change:
$ git cat-file --batch=batman --batch-all-objects
  batman 
  fatal: object 0000239 changed type!?  
and also has other subtle effects (e.g., we'd fail to stream a blob, since we don't realize it's a blob in the first place).

We can fix this by flipping the order of the setup.
The check for "do we need to get the object info" must come after we've decided whether we need to look up the type.

With Git 2.36 (Q2 2022), "git cat-file"^(man) learns --batch-command mode, which is a more flexible interface than the existing "--batch" or "--batch-check" modes, to allow different kinds of inquiries made.

See commit 440c705, commit 4cf5d53, commit ac4e58c, commit a2c7552 (18 Feb 2022) by John Cai (john-cai).
^{(Merged by Junio C Hamano -- gitster -- in commit d169d51, 09 Mar 2022)}

cat-file: add --batch-command mode

^{Helped-by: Ævar Arnfjörð Bjarmason}
^{Signed-off-by: John Cai}

Add a new flag --batch-command that accepts commands and arguments from stdin, similar to git-update-ref^(man) --stdin.

At GitLab, we use a pair of long running cat-file processes when accessing object content.
One for iterating over object metadata with --batch-check, and the other to grab object contents with --batch.

However, if we had --batch-command, we wouldn't need to keep both processes around, and instead just have one --batch-command process where we can flip between getting object info, and getting object contents.
Since we have a pair of cat-file processes per repository, this means we can get rid of roughly half of long lived git cat-file^(man) processes.
Given there are many repositories being accessed at any given time, this can lead to huge savings.

git cat-file --batch-command^(man)

will enter an interactive command mode whereby the user can enter in commands and their arguments that get queued in memory:
<command1> [arg1] [arg2] LF 
<command2> [arg1] [arg2] LF  
When --buffer mode is used, commands will be queued in memory until a flush command is issued that execute them:
flush LF  
The reason for a flush command is that when a consumer process (A) talks to a git cat-file process (B) and interactively writes to and reads from it in --buffer mode, (A) needs to be able to control when the buffer is flushed to stdout.

Currently, from (A)'s perspective, the only way is to either

kill (B)'s process

send an invalid object to stdin.

is not ideal from a performance perspective as it will require spawning a new cat-file process each time, and 2. is hacky and not a good long term solution.

With this mechanism of queueing up commands and letting (A) issue a flush command, process (A) can control when the buffer is flushed and can guarantee it will receive all of the output when in --buffer mode.
--batch-command also will not allow (B) to flush to stdout until a flush is received.

This patch adds the basic structure for adding command which can be extended in the future to add more commands.
It also adds the following two commands (on top of the flush command):
contents `<object>` LF 
info `<object>` LF  
The contents command takes an <object> argument and prints out the object contents.

The info command takes an <object> argument and prints out the object metadata.

These can be used in the following way with --buffer:
info `<object>` LF 
contents `<object>` LF 
contents `<object>` LF 
info `<object>` LF 
flush LF 
info `<object>` LF
flush LF  
When used without --buffer:
 info `<object>` LF 
 contents `<object>` LF 
 contents `<object>` LF 
 info `<object>` LF
 info `<object>` LF