There’s also an argument for having every exclusion centralised in one config file (ie gitignore) with regards to making it easier to review what exclusions are active.
As a DevOps guy (but with 30 years of experience in development too), one of my pet peeves is having to deal with a thousand different edge cases because someone decided that intellectual cleverness was more important than a holistic approach to design and architecture.
This change is only slightly better than the previous implementation. What we (and most I know) need is per-repo settings. Our organization has nearly 20 repos.
Not to mention every repo might have a different dev experience, different ways to test, different everything. Just multiplies dev ex pain times number of repos.
It just seems like such a miniscule benefit, and you have to deal with the massive headache of a multi-repo setup.
If you don't want people making changes to multiple projects at the same time, it would be trivial to add a pre-submit check to enforce that anyway. There's no need to switch your entire repository layout just to remind people that the code in different folders belongs to different projects.
You are going to have a ton of technical barriers in place if you are going to stop everyone from publishing to one of the many and varied code repos out there.
But imagine the increased productivity of your devs if they only had to check out a single repo. Anyone has the same organization of projects on their machine. All tools are in one place...
That requires everyone to have access to the repo, and to wade through it looking for changes to the relevant area of code you're working in. That sucks.
Something like a one repository limit would work well for me; enough to really get the feel, no real risk since I just revert to the web interface if I don't like it, but if it's good I'd definitely want to use it with more repositories.
This is funny, I stopped reading when it started talking about how engineer x will never touch section y of the code. Ok then put them in separate repos
Could this also help a smaller repo but with long history, making the total repo size too large?
The whole repo is needed for every developer - i.e it's not possible to do a sparse checkout but many gigs of old versions of small binaries I would prefer to keep only at the server until I need it (which is never).
Absolutely. I get they don't want to index every branch but at least set some heuristics like it it has a certain amount of activity or something per repo. Or even allow repo to opt into 1 to 2 other branches besides main. Especially for bigger projects
reply