If you can't understand atleast 70% of those lines of Git, you really should be using a git web app or something.

Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works.

Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.

Objects are your files. Underlying git is a content-addressable filesystem.

The objects are referenced by trees. A tree is just a directory.

The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references):

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs.

https://git-scm.com/docs/git-pack-objects

https://github.com/git/git/blob/master/Documentation/technic...

When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space.

https://github.com/git/git/blob/master/Documentation/technic...

Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!

But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above.

(Caveat: I'm working from memory and surely got some detail at least slightly wrong.)

Every place I worked at has a git introduction where all new employees learn about how git works internally. Takes 1h, and all junior devs stops memories random commands and actually start to understand. I highly recommend to you to poking around in the .git directory.

The git support for new employees drops basically to zero.

The lights are blinking, so everything must be working!

I’ve started using JJ vcs, mainly because some people were saying it was great and I didn’t really get it.

I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.

This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.

Those are just the sounds that animal makes. Live with the animal long enough, you learn how the sounds correspond to its internal states, even if you don’t really know what they mean.

I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push

Every Beagle command:

    gritzko@spot ~/beagle $ be get
     19:07  get ?#0ac49e6a
     16:58  post ?0ac49e6a#POST-018 put:/post: banner on stdout
     19:07  new beagle/test/be-post-put-banner.sh
     19:07  upd dog/INDEX.md
     ...more stuff...
     19:07  del test/post/01-bare-msg/01.put.err.txt
     19:07  del test/post/01-bare-msg/02.post.err.txt
     19:07  get abc?4222dfab

I bet most people don’t use the commandline client.

I actually like this underlying logs. Could have a concise / project level summary though.

Git as a data structure is clever, but Git as a CLI is atrocious.

I'd rather see some gobbledegook than extended pauses or idealized (read: fake) information. Those are specific tasks it is doing when you run that command, there's a simplicity to it.

Not saying Lore's approach is bad, but sometimes "worse is better".

I see Git as a tool aimed at experts that spend time to learn the tool. Asking non technical people to use it is a mistake. You can build guard railed apps on top of it for them, but probably it's the wrong tool.

This is what happens when a kernel developer creates tools that need some kind of UX (I say this both as a shitty UX developer and Linus fan)

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

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.

I use GitHub desktop app that pushes to my local Gitlab. It’s a nice and simple GUI, it might be what you’re looking for.

[dead]

[flagged]