491–500 of 717 posts
Earlier quoted context omitted.
Try gitolite? https://gitolite.com/gitolite/index.html It has fine-grained permissions but works with regular git clients.
Does it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.
[1] https://gitolite.com/gitolite/overview.html#what-is-gitolite
Is it me or I read in the docs "Design System" section that it was made in Scala then I went to double checked again an hour later and it said Rust
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…
> 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 tool…
This is the type of attitude that makes me regret ever commenting on HN.
FFS, git is a tool for programmers.
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…
That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering. Does Gitlab do better with this?
Earlier quoted context omitted.
That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this. Git enthusiast would often tel…
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
Earlier quoted context omitted.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.
The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood: - Pachyderm (Go): https://github.com/pachyderm/pachyderm - XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf - LakeFS (Go): https://gi…
Earlier quoted context omitted.
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
Earlier quoted context omitted.
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…
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 us…
> 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.)