Comment by niek_pas
9 hours ago
Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
I know all of these things communicate something to the die-hard Git user, but for most people (even most people using Git, I bet) this is just complete gobbledegook. What the hell is "delta compression"? Why do I care how many threads it's using? What is an 'object' and what does it mean when it's 'local'? What does 'pack-reused' mean?
From the documentation, it looks like Lore does a bit better in this regard:
Pushing 1 fragment(s)
Pushed 1 fragment(s), 124.00 bytes
Pushing a3f8c2d1... to branch main
Pushed revision 1 -> a3f8c2d1... to branch main
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.
> It's probably just something no one has thought of doing.
One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.
Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.
That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
1 reply →
Are those three really all the same things? That seems crazy to have all three not consolidated.
2 replies →
I understand there's friction in contributing to git, but it's absolutely possible to improve the docs:
Contributions from jvns:
https://github.com/search?q=repo%3Agit%2Fgit+jvns&type=commi...
Here she explains how she did it:
https://jvns.ca/blog/2026/01/08/a-data-model-for-git/
Contributions I've made:
https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu...
Generically:
https://github.com/search?q=repo%3Agit%2Fgit+documentation&t...
Do you have a link to your proposal on the git mailing list?
> It's probably just something no one has thought of doing
There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
Luckily it’s an open source project so you could go in and clean up the ux.
7 replies →
I do want a progress indicator for something that might take a while without asking. If you clone things locally, Git only reports that it cloned something.
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.)
> Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
This is the type of attitude that kept most Unix tools quite user-unfriendly for several decades. What information to show the user, and when, are important design decisions to make. Just dumping it all on the user and making them wade through it is not doing the user a favour. Thankfully newer tools seem to be better about this, which has brought the Unix shell forward by leaps, even if there's still ways to go. (You can still make a conscious design decision that the info needs to be all there, and git is one of tools where that's at least somewhat justifiable, but a lot of the time the attitude is more like in the quoted text, that dumping out more info is always better.)
> This is the type of attitude
This is the type of attitude that makes me regret ever commenting on HN.
FFS, git is a tool for programmers.
1 reply →
The point is that if it's useless information for 99.9% of users, what's it doing in the UI?
A percentage information for a network upload is very much not useless information. In fact making the user wait without any indication of progress is very bad UX.
It's not useless information, any more than the tachometer or a temperature gauge instead of an "idiot light" in a car is useless information. Again, "because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!"
If you don't want it, use `--quiet`. I like that it's there by default since it's useful when I need it and ignorable when I don't.
Of all the things to complain about git...
2 replies →
Now explain this to an artist with very little programming experience beyond what they picked up from their coworkers.
I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.
I'm not here to engage in rhetorical combat.
I was simply answering niek_pas's rhetorical questions, that's all, because maybe they piqued someone's curiosity and I can contribute a little of my esoteric knowledge about the inner workings of git. This is a site for the curious, yes?
Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.
Cheers.
1 reply →
It's a progress indicator. Everyone has had the concept of percent in school even if they are an artist.
> I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
Git is a software development tool first and foremost to support the development of an _operating system kernel_. It's perfectly reasonable for it to be technically verbose as a default, in the same way as it's reasonable for a band saw to cut off your finger if you use it without understanding things correctly first.
The problem git has in game development is not that the output is too complex, it's that it doesn't handle large binaries well (ironically enough, the focus of the replacement system in TFA).
1 reply →
Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.
2 replies →
Respectfully, I think you're missing the point. The GP is not asking for an explanation (and could look that up from the Git docs) but commenting on how user-hostile it is. There's lots of software like this, which is so unfriendly that once you've learned the minimum of how to do something and verify it worked, you don't want to touch it any more unless you really need to.
CLI output should be in plain language and omit or minimize unnecessary detail absent a -verbose flag - for example, I'm just not interested in how many threads something took unless I'm working on it. As a user, I want to be focused on the task I'm doing, not on the perfromance of the tool.
I dont think the problem is even verbosity here - it really isnt that much text.
The issue is what you and the above points out - it is not easy to read.
What might help dramatically is a simple modification of text (the verbose stuff could be slightly light grey and the important bits fully highlighted white) or even go full IRC with colored text, bold, etc.
Or hell - maybe instead they add a switch that inserts "//comment" like additionally lines to explain what is going on (succinctly) to the average Power User type. The default could be "software engineer" mode and the switch enable "Git for Dummies" mode.
3 replies →
Do you know what a rhetorical situation is? Do you understand that the parent was not actually seeking answers to these questions, but was using the questions themselves to make a point about the Git UI?
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.
The lights are blinking, so everything must be working!
Basically, sometimes there commands take a long time. It's nice to have feedback that something is happening even if it's just effectively a blinking light.
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.
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
I actually like this underlying logs. Could have a concise / project level summary though.
Every Beagle command:
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.
These criticisms of git always seems so shallow to me.
'add' tells git to start tracking some file(s)
'commit' tells git to save the currently tracked files
'push' says "upload my changes to some other location." Git isn't dropbox magically 'rsync'ing the directory to some server.
'pull' says "download any changes from some other location." Same deal as push.
That should satisfy the majority of git casuals that get frustrated with it. You should learn the tools of your trade, and version control (specifically git) is one of the tools of the software trade. If you work adjacent to software why is it so hard to learn a little about git?
You don't have to do add as a separate step unless you're adding it to the repo for the first time. You can (and I do) just `git commit file1 dir2` or whatever. I don't conceptually think commit+push should be combined; committing a version is separate from pushing it to a remote.
TIL! Thanks
When I was getting started with programming I often forgot to do one of those steps and often ended up losing my work because I was working from a library computer or something.
When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.
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 bet most people don’t use the commandline client.
Git as a data structure is clever, but Git as a CLI is atrocious.
But that's all Git originally aspired to be. It was supposed to be the base VCS, that you eventually can build a UI layer on top.
I feel like, everyone near Git has decided, "Well, all abstractions leak - so we might as well stand in the rain like Andy Dufresne when he escaped from Shawshank Prison!"
Obligatory: https://git-man-page-generator.lokaltog.net/
haha! The flaunt revisions flag is hilarious!
Is the tool taunting you?
1 reply →
this is such a good laugh. peak comedy
Yes, the famous debate between plumbing and porcelain
Still the porcelain is more like cold stainless steel
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".
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)
He makes a good tool? Honestly I don’t get the git hate on HN. I’ve been using it for years with no issue. I just read the first 3 parts of the git book and never looked back. I even setup a git server at home with the basic tools.
This is definitely a bit snarky but you read any of the documentation at all, and therefore know more than a large percentage of git users about what it’s actually doing. Most people seem to treat git like some sort of mysterious orb which if you speak the right incantations will perform magic for you.
2 replies →
Linus really has very little to do with git's development. He has stated that himself multiple times, and it's the factual truth. "This is what happens when a kernel developer creates tools..." is funny but not factual.
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.
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:
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.
The fact you took the time to explain this I think shows the problem. You did an excellent job.
Maybe what we need is one of those infographic things (or several - but not too many) that summarize the main terminology, actions, and basic architecture of how Git works. I've found those usually, when done right, can strike an ideal balance of reaching the largest amount of people. I personally prefer reading tutorials but I know plenty of talented people who instead prefer videos (which I personally hate) and a simple but visually pleasing graphic is right in between.
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]
What a completely rude comment that tells me everything I ever need about you and whether I'd want to interact with you. They're not asking for the literal answer. They're asking a question about why that is important to surface at all.
Sorry, you're right. It's been a frustrating morning and I shouldn't have taken it out on you.