How to assign different git per-folder permissions while you maintain the commit binding?

Question

Background

I've searched a lot and I am aware that different folder permissions under the same repository is something that is not supported by git. However, I still haven't found a satisfactory git model for my infrastructure although I've studied both submodules and subtree

References

In this point have to thank @VonC for his immense contribution to my understanding of those models

Infrastructure

I maintain a highly configurable application so most of my commits affect both the source and the configuration so I have placed them under a single git repository which structure looks like this:

.
└── myapp
    ├── README.md
    ├── source
    └── conf

Issue

My issue is that my conf directory needs to be exposed to the client (part of what makes my product highly configurable) who wants to perform a git-pull but for obvious reasons I don't want my client to get the source directory as well.

Workaround

.
└── myapp-conf
    └── "configuration"
.
└── myapp-source
    ├── README.md
    └── "sources"

This structure assumes two distinct repositories with no connection between them whatsoever, which doesn't meet my exact needs by saves me from the hustle submodules and subtree introduce,

Need

A way to:

associate a single commit ID to changes in both source and conf directories

while at the same time

being able to prevent the client from pulling my source code.

Sorry for the long question and thank you all in advance.

score 0 · Answer 1 · answered May 10 '17 at 19:46

associate a single commit ID to changes in both source and conf directories

That what a parent repo declaring those two subrepos as submodule does.

being able to prevent the client from pulling my source code.

That comes directly from the fact your source and conf repo are separate.

The main isse remains one of development: your project workspace wouldn't have source and configuration in the same parent folder, but rather in tow separate tree structure.

If possible, you should develop in another folder (different from the repos ones), with symbolic links tying the direct subfolder conf and sources to their respective and versioned directories in the Git repos.

.
└── myapp
    ├── README.md
    ├── source (symlink to mainrepo/myapp-source)
    └── conf   (symlink to mainrepo/myapp-conf)

mainrepo

  └── myapp-conf
  |   └── "configuration"
  |
  └── myapp-source
    ├── README.md
    └── "sources"

score 0 · Answer 2 · answered May 11 '17 at 11:04

You may not

prevent the client from pulling my source code.

given that the source code is located in a repository that the client can clone. Therefore having two repositories is required. I can see two different ways of creating and working with two repositories.

1. Keep working on the original myapp repository and use git subtree to create myapp-conf.

Associating commits is not an issue as work is done in the original repository and this is considered as the main repository. Each time configuration changes should be shared with the client, use git subtree push, to push the changes from myapp to myapp-conf. This is an extra step but you are free to squash the history or select branches to push, if needed.

2. Work on a multi-root project. Move "conf" & "source" one level up.

This is close to your current workaround. Create an empty directory "myapp" and inside it clone the myapp-conf & myapp-source repositories. The suggestion here is to name the cloned repositories "conf" & "source" and use git subdirectory-filter to move "conf" & "source" one level up (history rewrite !) in order to maintain a similar development environment.

To create myapp-conf:

git filter-branch --subdirectory-filter conf HEAD -- --all

To create myapp-source:

git filter-branch --subdirectory-filter sources HEAD -- --all

In this case, to