On Thu, Nov 12, 2009 at 10:31 AM, Nicolas Sebrecht <nicolas.s.dev@xxxxxx> wrote: > I don't understand. You'll still have to manually these files regardless > _how_ they are tracked. the first time i clone the repo I had to compile them manually... but then I would like to keep different setting in my different branches and I would like to find a way to "load" the right conf file automatically when I switch repo > When I say, "out of the main development repository", I don't think "out > of the directory of the repository" but "out of the tracking git system". of course, which is almost the same > I think you should look at 'git subtree' or 'git submodule' to track the > setting files out of the _main_ repository and _inside_ the main > development directory. will they work with git-svn? I'm not very familiar with them anyway. >> we are customizing a third party product and I can't change the way it >> is build up. >> >> I don't think that this situation is so uncommon anyway. > > Yeah, it doesn't help to be unable to do everything we want! But I'm > pretty sure git can do something very convenient in your case. you are right.. but since this is not so uncommon I think other people has found a way to handle it. May be using an external/local repository for those files. but then I would like to have a way to link them automatically. may be this can be achieved with some hook script.. What I have in mind is something like this: 1. creating a local repo "confrepo" on the same directory where I have the real repo 2. .gitignore for all my local config file in the real repo 3. using the confrepo to store my local scripts and replicate in it the same branch structure of my real repo 4. may be then I can create some hook script that when I do $ git checkout experimental a) it try to do the same on the confrepo (checkout experimental), if the branch doesn't exist it does nothing else b) copy everythink in the confrepo to my realrepo (overwriting if needed) that way I could have something automatic. The only think I couldn't have is, looking back in history, a way to know which config was in place for an old commit. could you tell me if this is even possible? I'm going a little off-topic here proposing an idea for a new feature What about adding a git feature to "link" different git repository? Or providing a way to have 2 (or more) git repository in the same working area. an ipotetical usage: $ mkdir realrepo && cd realrepo $ git (svn) clone http://whatever... . --> master $ git link createrepo ../confrepo confs --> Initialized repo ../confrepo --> Linked repo confs to ../confrepo --> Created branch master in ../confrepo $ touch localconf.properties $ touch real-repo-file.c $ git add real-repo.file.c --> added real-repo-file.c to stage (as usual) $ git link add localconf.properties --> Added local.conf.properties to confs stage $ git commit --> standard commit --> added localconf.properties to .gitignore (or .git/info/exclude) --> commit on confs $ git checkout -b experimental # creating new branch --> checkout -b experimental on confs $ # modify many things and the localconf.properties $ git status --> show standard output and on new section "linked files": localconf.properties on confs has been modified $ git add . && git commit --> localconf.properties is committed in "confs" repository branch "experimental" $ git checkout master --> checkout master on confs --> copy all files of the confs repo to the current real repo working area I think you got the idea. the "linked" repo could also keep a tracked files like this: .gitlink-source which could keep the commit SHA of the real repo for each commit in the confs repo so that you had a way to get the right "confs" commit associated with each commit on the real repo. I don't know git enough to see how this could be hard or which drawback could have. -- 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