git remote_cache: why not checkout from a bare/mirrored repository?

[bkw]

Hi *,

being a new capistrano (and ruby-) user I wonder whether the use of
git with :remote_cache could not be made more effecient. Right now, we
copy the whole checkout including the .git directory for every
release.
IMHO the following would be much faster and more space efficient:

# first checkout of the repo cache as a bare. (only done once):
git clone --mirror #{repository} #{repository_cache}

# update the repo cache before each checkout:
git --git-dir=#{repository_cache} fetch #{repository}

# checkout a release from the repo cache:
mkdir #{release_path} && \
cd #{release_path} && \
git --git-dir=#{repository_cache} --work-dir=. reset --hard #
{branch}


This way we would keep a bare repository without any checked out files
current in the repository cache, and produce a quick and slim checkout
for the release without duplicating the whole .git directory
everytime.
This would save both deployment time and storage space, in my case
quite significantly.

Did I overlook a compelling reason not to go this route? I'm about to
dig into cap's internals to try to implement this (as a plugin
maybe?), but before I waste my time on something stupid, I'd rather
ask for advice here.

Any thoughts?
bkw

[Jamis Buck]

There's no reason you need to copy the .git directory. Just set
:copy_exclude to %w(.git) and it should ignore that directory.

As for why it's implemented the way it is: it's for compatibility with
other SCM's. Git is not the only SCM capistrano supports, so the
built-in deployment strategies have to support the "lowest common
denominator". By all means, though, implement your idea and release it
as a git-specific deployment strategy. If it's useful to you, I'm sure
it'd be useful to others.

- Jamis

[David Masover]

I actually implemented something which did a git-clone from the cache instead (while still keeping the cache itself bare). Since git-clone uses hardlinks by default, it's almost as space-efficient, with the added coolness of being able to check in (and then merge) any changes that happen there.

I'm not saying it's a good idea, but it was helpful with things like Mephisto themes -- anytime an application might make changes to files in the source distribution, and you want those changes back in the repository.

Unfortunately, that makes it even less portable to other SCMs. Worse, it may be awhile before I can release this...