On Thursday, August 15, 2013 01:46:02 am Stefan Beller wrote: > On 08/15/2013 01:25 AM, Martin Fick wrote: > > On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy > > > > wrote: > >> Antoine Pelisse <apelisse@xxxxxxxxx> writes: > >>> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller > >>> > >>> <stefanbeller@xxxxxxxxxxxxxx> 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. > > > > I didn't review the proposed C version, but how was it > > planning on removing the dependencies on these > > binaries? Was it planning to reimplement mv, cp, find? > > These small programms (at least mv and cp) are just > convenient interfaces for system calls from within the > shell. You can use these system calls to achieve a > similar results compared to the commandline option. > http://linux.die.net/man/2/rename > http://linux.die.net/man/2/unlink Sure, but have you ever looked at the code to mv? It isn't pretty. ;( But in all that ugliness is decades worth of portability and corner cases. Also, mv is smart enough to copy when rename doesn't work (on some systems it doesn't). So C may sound more portable, but I am not sure it actually is. Now hopefully you won't need all of that, but I think that some of the design decision that went into git-repack did consider some of the more eccentric filesystems out there, -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html