3 ms·
Perhaps the issue is that there's no technical barrier to them messing around with something else, perhaps by accident. (And if you try to deal with this by pl
by rst 12y ago
Perhaps the issue is that there's no technical barrier to them messing around with something else, perhaps by accident. (And if you try to deal with this by playing around with filesystem-level write positions in the repo, then they can't pull down new versions of the rest of the project either.)
The only really clean solution is to use submodules (or the newer variation on the theme, git subtree). But those aren't entirely smooth either.
- bluecalm 12y agoThe idea of Git is that everybody has their own local copy of a whole repo so it doesn't really matter what they do with it or if they mess it up. If other people want to merge the changes to their repos they will see what was changed and what wasn't so if you get pull request from "XML only guy" you just verify if only XML files were changed. You seem to think about it in terms of one master which isn't Git way.
- rst 12y agoAnd you're thinking about a workflow in which no one ever uses "git push". If most devs do, and "the XML guy" can't (because someone else needs to look over his commits), that's a headache, which could be solved technically. Come to think of it, it could be solved technically even with git -- the XML guy's repo gets a pre-commit hook that verifies that he's committing changes only to the files he's allowed to edit. (We're now requiring him not to mess with that hook, but if that's a problem, maybe they shouldn't have source code access at all. The point is that now a tool is doing the checks, which frees up the humans for things that really do require human judgment.)