Michael J Gruber wrote:
I wonder whether a clever use of "excludes" and GIT_DIR would allow tracking the different filesets in the same dir, but using different repos. I'm just afraid it's a fragile setup, in the sense that it relies on config stuff which is not tracked (and thus not reproduced automatically on clone).
I expect that using a superproject repository to tie together the two repositories is good and necessary because it is the link that allows to specify which commit in the repo of generated files belongs together with a commit in the repo of source files. So just using two separate repositories without making them submodules of a superproject does not seem to be a good idea to me.
Once there is a superproject repository, one could also commit config files of the submodules into it (I'm not sure what that will buy though--.gitignore is outside and can committed anyway, at least as long as not both repositories are overlaid as you suggest).
You're probably right that strictly speaking, there is no need to move generated files out into a separate directory tree; but I think doing the move would be worthwhile since it takes away one level of complexity (you can then access the build/.git repository without the need of setting GIT_DIR), and because it may be a good idea anyway (for example it will be easier to grep the sources without getting hits from the generated files). [Also, the exclude patterns wouldn't be easy, as we couldn't really just exclude all *.c files from the view of the source repository, since there are also some hand-crafted ones; the excludes would need full paths which would have to be kept up to date manually, unless we wanted to live with the fact that newly created manual .c files would be added using "git add -f".]
Christian. -- 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
