How to have multiple working copy directories use the same repository?

How to have multiple working copy directories use the same repository?

[Bill Priest]

All,
  My current business requirements make it
advantageous to have two concurrent working
directories (that have similar file structure; but not
exactly the same); I need to maintain two separate
builds that are always up to date.  Each working
directory would be associated with a particular
branch/line of branches (think of two different
hardware platforms that have considerable overlap).  A
complication to this is that I need to use git-svn as
the remainder of the team uses svn (I just changed
from cvs to svn last Jan so it is a hard sell to
management to change again).  I'm using git for the
merge capabilities.
  I've looked at the "git for CVS users" section in
the docs and this appears to create two repositories. 
Is there a way to have two working directories that
utilize the same repository?
  I'm betting that I'm just trying to push my workflow
style onto git instead of adapting to the git way of
doing things; but thought I would ask.

TIA,

Bill
PS.  I'm trying to avoid the push in the commit, push,
merge, dcommit cycle.



       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

Re: How to have multiple working copy directories use the same repository?

[Alex Riesen]

Bill Priest, Thu, Oct 11, 2007 20:10:50 +0200:
>   I've looked at the "git for CVS users" section in
> the docs and this appears to create two repositories. 
> Is there a way to have two working directories that
> utilize the same repository?

Look for "alternates" in git's documentation. But read all the
warnings regarding git-gc and git-prune. Make a note of ".keep" files.

>   I'm betting that I'm just trying to push my workflow
> style onto git instead of adapting to the git way of
> doing things; but thought I would ask.

Git is flexible enough to accomodate almost any existing workflow.
Just some of them work better.

Re: How to have multiple working copy directories use the same repository?

[Sergio]

One possibility can be to use the "git-new-workdir"
script that is distributed in the contrib directory
of git source. It allows to have many work dirs insisting
on the same repo (yet possibly operating on different branches!)

I believe that you might need to be careful with that,
though:

1) There is no check about the possibility of messing things
up by working on the same branch from two points.
2) There should be a basic infrastructure to avoid nasty
things from happening but I do not know if it is complete.
3) Implementation is based on symlinks in the git directory,
so it is only for architectures supporting symlinks and, since
there are many symlinks, if something gets changed by mistake and
some symlink looses consistency with the others bad things may
happen.

Sergio  

Re: How to have multiple working copy directories use the same repository?

[Shawn O. Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> Bill Priest, Thu, Oct 11, 2007 20:10:50 +0200:
> >   I've looked at the "git for CVS users" section in
> > the docs and this appears to create two repositories. 
> > Is there a way to have two working directories that
> > utilize the same repository?
> 
> Look for "alternates" in git's documentation. But read all the
> warnings regarding git-gc and git-prune. Make a note of ".keep" files.

Really I think Bill wants the contrib/workdir/git-new-workdir script.

Its downside is that it makes heavy use of symlinks under the
.git directory for the secondary working directories, and you do
have to watch out for committing changes to a branch when more
than one working directory has that branch as its current branch.
But otherwise it works very well for this use case.

Also you may get a few warnings from your HEAD reflog saying objects
no longer exist when you do a git-gc within a working directory.
This can happen for example if you use `git rebase -i` in a working
directory a few times and then later run git-gc from a different
working directory.  But since its just intermediate rebase state
its probably not that big of a deal to have it go missing.

You shouldn't run `git gc --prune` if any of the working directories
has staged but uncommitted changes in them.  Such changes are held
in the working directory's index, which will not be considered
as reachable (as it isn't visible to git-gc) and the objects will
be pruned.  That would not too be pleasant to debug.

Heh.  As you can see it has some "issues" with its use.  Its a very
powerful tool, but it does give you more than enough room to shoot
yourself in the foot.  Using it is like tieing a gun to your ankle,
keeping it aimed at your big toe at all times, with a string tied
to your wrist and the gun's trigger.  Reach too far and *bam*.
Which is why its still in contrib status.
 
-- 
Shawn.