Luciano Rocha wrote:
> git clone server:/rep ~/master
> git clone -s ~/master build/abc
> git clone -s ~/master build/foo
> ...
Don't do that without first doing
git config gc.pruneExpire never
to disable pruning loose objects if there is any chance that any will
be created. Better to be safe, and prune manually using the example
in the prune documentation.
> The -s option should reduce disk-usage considerably.
It won't be any less than what git-new-workdir would produce. Actually,
git-new-workdir could provide more space savings since there is only a
single repository so new objects created by development in any of the
new work directories would be available to all others. This is getting
a little nit-picky, basically space usage for the two options is nil.
My take on it...
If you want to have _multiple_different_ branches checked out from the
_same_ repository, and do development in all of them, then git-new-workdir
is the right choice.
If you want to have the _same_branch_ checked out in multiple work
directories, then cloning with -s is what you want. In this case
I assume development will be performed in the original repo, and
the clones will do a pull to update.
Personally, I have found the git-new-workdir script to satisfy any
need which caused me to even think about cloning with -s. I am
hoping the functionality of git-new-workdir will be folded into
git porcelain at some point (ahem J Schindelin).
-brandon
--
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
