Re: Git-new-workdir

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: May 21, 2008, 19:25 UTC
Message-ID: <MnNeABMJjOQ8gdG6gY5zubSC3c5X2sDYBwcI1MotmXFvW3kUNXzB5A@cipher.nrlssc.navy.mil>
In-Reply-To: <20080521184446.GA23924@bit.office.eurotux.com>

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