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