You don't care about any of this information, but that's fine; unless something is going wrong, you can ignore any information that isn't interesting to you.

Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant.

In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on.

Case in point, this is the output I get when I try to clone the Linux kernel:

    Cloning into 'linux'...
    remote: Enumerating objects: 11623749, done.
    remote: Counting objects: 100% (396/396), done.
    remote: Compressing objects: 100% (189/189), done.
    Receiving objects:   1% (181683/11623749), 90.11 MiB | 19.17 MiB/s

Generally not useful information most of the time, but if I didn't have it I would be staring at a blank terminal for an hour wondering what was happening.

Also, I assume you're not but in case anyone is interested in the answers to these questions:

> What the hell is "delta compression"?

The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next.

For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB.

> Why do I care how many threads it's using?

Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'.

> What is an 'object' and what does it mean when it's 'local'?

Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object.

Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has.

> What does 'pack-reused' mean?

To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.

Epic Games announces Lore version control system