Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lore – Open source version control system designed for scalability

lore.org

Post reply on HN
Print view View original

671–680 of 717 posts

Re: Lore – Open source version control system designed for scalability

#671

Post by usrbinbash »

LugosFergus wrote: post #62
throw2ih020 wrote: post #24

For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to o…

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't plann…

> Something else that git isn't good at: permissions.

It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.

Re: Lore – Open source version control system designed for scalability

#672

Post by wtetzner »

sundarurfriend wrote: post #512
js2 wrote: post #493

Earlier quoted context omitted.

> 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 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 readin…

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

Re: Lore – Open source version control system designed for scalability

#673

Post by jayd16 »

Hendrikto wrote: post #647
jayd16 wrote: post #222

Earlier quoted context omitted.

P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.

Git has had native partial checkout for ages.

Do you know any large, non-technical teams that use it? The workflow is just not feasible even if the feature technically exist.

Things like submodules become even more complex. Without submodules there's no equivalent to map in library/engine code into place in a way where you can push changes back upstream.

Last I checked, things like logs and pulling still operate on every commit so it doesn't really scale the same way.

Re: Lore – Open source version control system designed for scalability

#674

Post by wtetzner »

genocidicbunny wrote: post #555
1718627440 wrote: post #514

Earlier quoted context omitted.

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

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 mea…

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.

Re: Lore – Open source version control system designed for scalability

#675

Post by wtetzner »

dijit wrote: post #415
mariusor wrote: post #388

Earlier quoted context omitted.

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

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 extr…

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

Re: Lore – Open source version control system designed for scalability

#676

Post by wtetzner »

genocidicbunny wrote: post #398
mariusor wrote: post #388

Earlier quoted context omitted.

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 le…

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

Re: Lore – Open source version control system designed for scalability

#677

Post by wtetzner »

anigbrowl wrote: post #306
js2 wrote: post #136

Earlier quoted context omitted.

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 ob…

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…

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.

Re: Lore – Open source version control system designed for scalability

#678

Post by wtetzner »

abustamam wrote: post #413
yjftsjthsd-h wrote: post #405

Earlier quoted context omitted.

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

You can also just do `git commit -a` to commit all modified files.

Re: Lore – Open source version control system designed for scalability

#679

Post by troupo »

moogly wrote: post #359
LtdJorge wrote: post #148

Earlier quoted context omitted.

Casey was right, though. The windows terminal was (is, it's still there even if you use the new Terminal) atrocious. The performance is so bad, due to going through all the layers it does, which Casey exposed. And it's not even packed with features, pressing up on a new console doesn't bring you a command from history, which Linux terminals and 3rd party Windows ones have been doing for decades, even Powershell does…

Imagine if he had approached it like, e.g. Bruce Dawson though, instead of coming off like an edgelord off his meds.

He did approach it correctly, and then his questions were dismissed because "it needs PhD-level research". If anything, it was clueless and incompetent Microsoft "engineers" who acted as edgelords.

Re: Lore – Open source version control system designed for scalability

#680

Post by bentt »

robaato wrote: post #655
bentt wrote: post #261

There was and still is a very nice competitor in this space called PlasticSCM. They were bought by Unity a few years ago. Unity has not been a good steward. They should have done what Epic is doing and open sourced it. But instead they chose to give it P&L responsibility. Curious what it's contributing to their financials.

Plastic is usable on surface, but doesn't scale well. If you've ever looked at what Plastic does when you use its git fast-export compatible feature, the results for merge commits are horrible to behold, e.g. delete of a directory followed by add of a file into same dir, then delete of it then rename.

I’m not picking up how its git export feature maps to its scalability.
Post reply on HN