Re: [RFC PATCH] repack: rewrite the shell script in C.

> On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
> 
> wrote:
> > Antoine Pelisse <apelisse@gmail.com> writes:
> > > On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> > > 
> > > <stefanbeller@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.
> 
> 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?