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. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
