On Fri, Nov 4, 2011 at 12:21 AM, Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> wrote: > ----- Original Message ----- > From: Eugene Sajine > Date: 11/3/2011 1:28 PM >> >> Are you sure that the way your have organized the repository is >> actually correct? If you need to manage the access on folder level why >> don't you simply split up the project into several >> repositories/projects which each team is going to work with >> independently? >> >> This seems to me to be much simpler and cleaner solution then any >> other alternative. >> > Submodules are _not_ simple at all. Our organization of nearly 100 > developers using Git pretty much let out a collective cheer when we finally > removed the submodules. Submodules are an absolute pain to develop within; > there are a number of Git mailing list exchanges about that, but I'd be > happy to go into great detail if anybody cares. Even submodules that are > read-only are a pain as it takes two steps (git pull + git submodule update) > to actually get them up to date. > > Ick. > > In short, if it is an absolute requirement to manage access to a repository > on a folder level, get Subversion or Perforce. DVCS is not for you... > > Josh > That is exactly what i wanted to say. I suggest OP not to go into submodules, but just have separate repositories. I think if they need this kind of granularity in permissions it means that their repository is too big and incorrectly organized. I think they are trying to migrate to better VCS (as git is superior by definition;) ), but they still think in central VCS terms and that's what causing this folder level management requirement to appear. We at $work have hundreds of repositories and never had any need of submodules or folder level permissions. (One repo = one project = one artifact) + Ivy as dependency manager works just fine and if we will need to fine tune the permissions it will be always pretty easy to do. Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html