[js2]

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.)

[sundarurfriend]

> 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.)

[ghthor]

Of all the places to complain about a problem like this…

[js2]

> 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.

[sundarurfriend]

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.

[wtetzner]

I dunno, I feel like it's useful output. Sure, maybe you don't need all of the details, but it's effectively a progress indicator to let you know something's happening and it's not "stuck". Why not include useful debug information within the progress indicator so that if something fails part way through a big push, you have useful information for debugging it (or Googling it)?

[zackwu]

I'm a programmer and I understand Git internals decently well, but unless something went wrong, I pay zero attention to the verbose output of `git push`. BTW, isn't "avoid unnecessary output" one of the Unix philosophies?

[squeaky-clean]

> FFS, git is a tool for programmers.

We already said it has a garbage UI, you don't need to repeat it

But jokes aside, usually the reason something is considered a "tool for programmers" and not just a tool is because the UI sucks.

[dansmith1919]

The point is that if it's useless information for 99.9% of users, what's it doing in the UI?

[1718627440]

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.

[dansmith1919]

I feel like you’re either misunderstanding the entire thread or being obtuse on purpose.

The point is that “Delta compression using up to 10 threads” means nothing to most users - it’s also not a progress thing. Hide it unless the user does -v or something.

[js2]

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...

[gbalduzzi]

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

[js2]

Are you not a programmer? Do you not ever find yourself having to debug an issue? When you have to, are you not glad when there's sufficient information in the log files to do so, even though 99.9% of the time you never look at the logs?

> Imagine typing cd folder

It's not comparable. `cd` is a local command (technically a shell built-in) that completes instantly (unless you cd to a hung NFS mount...). So it honors the Unix philosophy of emitting nothing on success.

But cloning is a network operation. And it's normal for networking tools to output progress by default. See `wget` and `curl`.

The problem with hiding progress under `--verbose` is that by the time you need the information (why is this taking so long?), it's too late to add `--verbose`. You'd have to cancel the command and run it again losing progress.

If you don't want it, then use `--quiet` and move on with your day.

(Sure you could make it smarter by deferring outputting anything until it realizes the operation is taking some time. Patches welcomed.)

[genocidicbunny]

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.

[js2]

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.

[genocidicbunny]

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.

[jen20]

> 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).

[genocidicbunny]

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.

[jen20]

> but those that are not 'in the know'.

Those are not the target market, and that is OK.

> spending extra time to get into the weeds of a version control system is often not possible without sacrifice.

Which is why most Gamedev places use perforce and not git. Or, perhaps now, Lore.

[1718627440]

It's a progress indicator. Everyone has had the concept of percent in school even if they are an artist.

[genocidicbunny]

No, it's mostly nonsense to them.

You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.

Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.

[wtetzner]

Do you really think that the `git push` output matters in one way or the other to artists?

I feel like the blocker is understanding how to use git, not the output of `git push`. It just feels like a bad example.

[qwery]

git is not a particularly suitable VCS for gamedev for reasons so much deeper than what messages it prints for a given command. git is a tool built to solve versioning text files in a collaborative, open software development context. That is the problem git has in the gamedev space.

[mariusor]

Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.

[dijit]

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).

[mariusor]

> Git for game dev is brittle,

You're basically reinforcing my point which was that the artist argument is a straw man, and companies that need artists to interact with version control will most likely use something else than git.

[wtetzner]

What do you mean about the short lived branches? Long lived branches work just as well in git as anywhere else (and it's easy to keep them mergeable by keep master merged into your branch).

[genocidicbunny]

> 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.

[wtetzner]

> 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.

How is this different from any other piece of software ever? When things go wrong, the artist is stuck either way. The only solution is software that always works...

[feelamee]

I don't understand - you arguing that artists should learn to use cli? if so, "programmish" git output is not a problem, because they already not just artist, they learned git.

But, for me this looks like this - if artist need to go to cli to solve some error, then this is bug or leaky abstraction in GUI client.

[anigbrowl]

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.

[Melatonic]

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.

[9dev]

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.

[genocidicbunny]

That is exactly what one of my earliest CS teachers taught me.

No news is good news.

[1718627440]

Because it is a progress indicator, that you stare at while waiting. Even Youtube does that and that is written for the general population.

[wtetzner]

I'm struggling to understand how this output is a problem. There a whole bunch of things that make git user-unfriendly, but I don't think this is one of them.

I think it's disingenuous to suggest that the `git push` output is somehow adding friction to users. Do you really think that even non-programmer users won't just read it as "it's still doing stuff"? Sure, you could hide it behind a --verbose flag, but then if it fails half way through, it's too late to add the flag. Even a user who doesn't understand the output could then copy/paste it into Google or an LLM to figure out what happened.

[mvdtnz]

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?