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

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

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

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. 

mkdir, test, chmod are also easily done via system calls.
The system calls are usually capsulated by the libc to have
an easy C interface. (A standard C function call)

sed and find are tricky indeed, but you can get around it with
a few lines of C (maybe 10?) for each occurrence. We don't need
the full power of sed and find, but rather only the exact specific
matching regexp.

 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?

The C version as of now has twice the lines of code than the
shell version. And I am pretty sure I did some rookie mistakes,
so the code can be down-sized by better use of already existing
functions. So I guess the final version will have less lines than
in the proposed patch as of now.