Antoine Pelisse <apeli...@gmail.com> writes:
> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> <stefanbel...@googlemail.com> wrote:
>> builtin/repack.c | 410
>> contrib/examples/git-repack.sh | 194 +++++++++++++++++++
>> git-repack.sh | 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html