Comment by js2
8 hours ago
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.
And yet, even for programmers, that output is full of info that is useless 99.9% of the time. That is just bad design. It is basically a debug log that is shown by default all the time, instead of written to a log somewhere for the <0.1% time it's useful.
And I point out the attitude because I've seen it for decades and seen the harm this kind of "it's just harmless extra info" type thinking has brought. I don't know what tone you're reading into it, but I'm quite literally and explicitly criticizing the attitude, not you personally.
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...
How often do you really need to look at that info while doing normal work?
Because to me and to the very vast majority of git users it is totally irrelevant.
It is nice that the info is available, but the more sane default would be to hide under a verbose flag not the other way around.
Imagine typing cd folder/ and have the whole filesystem subtree be displayed in the terminal. You are free to ignore it, but it is useless and inconvenient nonetheless
1 reply →
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.
I apologize if I came off harsh and combative. Gamedev is a passion for me and I spent many years in that field, including working on proprietary version control systems because existing ones like SVN, Git, Perforce...etc did not fit the needs of the team.
One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.
Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.
I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.
> 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.
Precisely, and I think Lore is an interesting proposition for exactly that reason.
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).
While I agree that git is a tool for the development of an operating system kernel, it's become clear that this is not the general perception of it. I don't mean those of us who have followed it throughout it's evolution, but those that are not 'in the know'. I have heard probably too many programmers pushing it as the end-all-be-all solution for version control even in environments not appropriate for it.
I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.
Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.
> artist should use any of the nice frontends that work on top of git and hide its verbosity.
Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.
It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.
Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors.
Or, you need to lock your files and git doesn't really support that.
To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.
Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).
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.
and why don't we just follow decades of conventions and add a --verbose/-v flag to display all the gobbledegook if you really want to, but hide it by default? As far as I remember, the guidance has always been "only print something if the user needs to know, no output means success."
git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.
2 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?