this post was submitted on 17 Jun 2023
9 points (100.0% liked)
Programming
13226 readers
2 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Do you mean a bare repo you use as a remote and push/pull from or using the workdir straight from the share. The first would be strange, but kinda usable (don’t do this though), the latter is oh my god, get an other job category.
Working from the network share - I've worked on a project like this before, it was awful for developer experience. It took seconds to run a
git status
, it was so slow. Occasionally git would lock itself out of being able to update files, since the network read/write times were so slow. Large merges were impossible.The reason it was set up like this was that the CEO had the network share we were working off of set up to serve to a subdomain (so like, Bob's work would be at bob.example.com), and it would update live as most hot-reloads will do. He wanted to be able to spy on developers and see what they were doing at any given time.
I have a lot of programming horror stories from that job. The title of this thread brought up a lot of repressed memories.
Yes, it's definitely the former case, thankfully. Agreed that it's strange, but it's hard to put a technical reason behind it if I decide to push for hosting it somewhere better.
Why not just host a server in house?