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

On Thursday, August 15, 2013 01:46:02 am Stefan Beller 
wrote:

On 08/15/2013 01:25 AM, Martin Fick wrote:

quoted

On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy

wrote:

quoted

Antoine Pelisse [off-list ref] writes:

quoted

On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller

[off-list ref] wrote:

quoted

 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