Re: Locally manage user/branch setting files without pushing them remotely

From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Date: Nov 12, 2009, 11:15 UTC
Message-ID: <20091112111530.GC25398@vidovic>
In-Reply-To: <9accb4400911120213w35efcad3q8a24d99c37a5e8c5@mail.gmail.com>

The 12/11/09, Daniele Segato wrote:

Show 7 quoted lines

> 
> > 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.

Not the way you'd like to, I think. This could mean having as many svn repo as git subtree/submodule.

> 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..

You could look at 'man githooks'.

Show 23 quoted lines

> 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 think, yes.

> 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.

Patches are welcome. That said, I guess it won't be needed. As you pointed out, the flexibility has been implemented in the hooks system. Consequently, we all have to write the appropriate scripts. But OTOH, it is more flexible than any feature matching _one_ workflow.

-- 
Nicolas Sebrecht