351–360 of 717 posts
Too bad it does not support fully local/detached (without server). It would be nice to be able to run it similar to a local repo without remote
There are some awkward workarounds (officially supported ones) which create a local server and you then merge with a remote server upstream, but as you might expect: its awkward and practically nothing supports the workflow.
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…
My teaspoons are terrible at peeling potatoes. Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control. I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.
Earlier quoted context omitted.
I was. I thought, and still think, that svn was much more pleasant to use than git. Alas, I am in the minority.
SVN was more straightforward to use, but that straightforwardness lost a lot in terms of fidelity. The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a…
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…
My teaspoons are terrible at peeling potatoes. Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control. I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.
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…
Too bad it does not support fully local/detached (without server). It would be nice to be able to run it similar to a local repo without remote
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…
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 ne…
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 always wondered if a combination of a database to index assets and asset versions with the data being in S3 style storage would be better for game assets; code can be in Git. Then your workflows are easy to build on top of that.
Earlier quoted context omitted.
And then they usually back their words by doing things like "you claim that outputting text to a terminal emulator is a PhD level problem, so here I did it in a weekend". Huge teams are more often than not the sign of bloat and inefficiences.
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…
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…
One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github. If there is an asset that is updated very frequently in the early stage of development, you'll be charged for all the storage for the rest of the repo's life. That happens a lot in gamedev: most assets…