441–450 of 717 posts
After tearing it apart for 2 hours - it seems like a solid beginning, but definitely not a fully-functioning product (especially on Mac, I hope it works better on Linux/Windows).
Disclaimer - I'm one of Diversion's founders.
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…
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
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…
P4 is also really well integrated into IDEs and UE Editor so that I don't need to think about it as much as I need, compared to Git. Locking assets, releasing them, merging into streams etc., is overall pretty streamlined. When it works, it's great, but when it doesn't work though, it's pretty hard to diagnose issues.
The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important.
I worked with P4 around the time I first started learn git (coming to both from SVN). P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git". So glad to be far, far from that particular tool now.
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 obje…
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.
'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?
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 obje…
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…
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.)
Earlier quoted context omitted.
Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.
check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source. Delta patches become effortless
It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).
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…
The point is that if it's useless information for 99.9% of users, what's it doing in the UI?
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...
Earlier quoted context omitted.
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…
Try gitolite? https://gitolite.com/gitolite/index.html It has fine-grained permissions but works with regular git clients.
Earlier quoted context omitted.
P4 is also really well integrated into IDEs and UE Editor so that I don't need to think about it as much as I need, compared to Git. Locking assets, releasing them, merging into streams etc., is overall pretty streamlined. When it works, it's great, but when it doesn't work though, it's pretty hard to diagnose issues.
One of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent. The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important. I worked with P4 around the time I first started…
Earlier quoted context omitted.
A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things. In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace. For example: - p4 trac…
> p4 predates most of the VCSes we consider "modern" p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.