Antoine Pelisse <> writes:

> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> <> wrote:
>>  builtin/repack.c               | 410 
>> +++++++++++++++++++++++++++++++++++++++++
>>  contrib/examples/ | 194 +++++++++++++++++++
>>                  | 194 -------------------
> I'm still not sure I understand the trade-off here.
> Most of what git-repack does is compute some file paths, (re)move
> those files and call git-pack-objects, and potentially
> git-prune-packed and git-update-server-info.
> Maybe I'm wrong, but I have the feeling that the correct tool for that
> is Shell, rather than C (and I think the code looks less intuitive in
> C for that matter).

There's a real problem with git-repack being shell (I already mentionned
it in the previous thread about the rewrite): it creates dependencies on
a few external binaries, and a restricted server may not have them. I
have this issue on a fusionforge server where Git repos are accessed in
a chroot with very few commands available: everything went OK until the
first project grew enough to require a "git gc --auto", and then it
stopped accepting pushes for that project.

I tracked down the origin of the problem and the sysadmins disabled
auto-gc, but that's not a very satisfactory solution.

C is rather painfull to write, but as a sysadmin, drop the binary on
your server and it just works. That's really important. AFAIK,
git-repack is the only remaining shell part on the server, and it's
rather small. I'd really love to see it disapear.

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to