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

[Martin Fick <mfick@codeaurora.org>]

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@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?
> 
> 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