Re: [gambit-list] Separating generated files? (Re: Mercurial -> git)

[Christian Jaeger <christian@pflanze.mine.nu>]

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.