On Fri, 30 Dec 2011 13:41:57 +0100
Richard Hartmann <richih.mailingl...@gmail.com> wrote:

> On Fri, Dec 30, 2011 at 11:33, Dieter Plaetinck <die...@plaetinck.be>
> wrote:
> > I don't understand what you mean. can you explain all the steps
> > involved so that I get where the problem lies?
> When I clone, I need a place to clone into. If that information is
> stored in the repo which I am about to clone, I can not access the
> storage location before storing it... Chicken, meet egg.

to clarify, I actually meant GIT_WORK_TREE (which equals VCSH_BASE)
i.e. this is not about where to clone the repository too (or well, that might 
be a problem too in the described use-case but you can always just choose 
unique repo names to avoid collisions),
it's about where git should put the files brought forth by the repository.
so it's not a chicken-egg problem, although there is a problem, and that is 
that the `worktree` setting is stored in .git/config which doesn't get passed 
by cloning, fetching or merging. 
I'm not sure yet whether we can set configuration per-repository _and_ pass it 
when cloning/fetching, but at least we only need to know the worktree setting 
just before the actual `git merge origin/master` step (i.e. after the fetch), 
so something like versionning the actual config within the repo would work.

vcs-home mailing list

Reply via email to