On Wednesday, August 14, 2013 05:25:42 pm 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? Were there > other binaries that were problematic that you were > thinking of? From what I can tell it also uses test, > mkdir, sed, chmod and naturally sh, that is 8 > dependencies. If those can't be depended upon for > existing, perhaps git should just consider bundling > busy-box or some other limited shell utils, or yikes!, > even its own reimplementation of these instead of > implementing these independently inside other git > programs? Sorry I didn't comprehend your email fully when I first read it. I guess that wouldn't really solve your problem unless someone had a way of bundling an sh program and whatever it calls inside a single executable? :( I can see why you would want what you want, -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