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

[Martin Fick <mfick@codeaurora.org>]

On Wednesday, August 14, 2013 10:49:58 am Antoine Pelisse 
wrote:
> 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).
> I'm not sure anyone would run that command a thousand
> times a second, so I'm not sure it would make a
> real-life performance difference.

I have been holding off a bit on expressing this opinion too 
because I don't want to squash someone's energy to improve 
things, and because I am not yet a git dev, but since it was 
brought up anyway...
 
I can say that as a user, having git-repack as a shell 
script has been very valuable.  For example:  we have 
modified it for our internal use to no longer ever overwrite
new packfiles with the same name as the current packfile.  
This modification was relatively easy to do and see in shell 
script.  If this were C code I can't imagine having 
personally: 1) identified that there was an issue with the 
original git-repack (it temporarily makes objects 
unavailable) 2) made a simple custom fix to that policy.

The script really is mostly a policy script, and with the 
discussions happening in other threads about how to improve 
git gc, I think it is helpful to potentially be able to 
quickly modify the policies in this script, it makes it 
easier to prototype things.  Shell portability issues aside, 
this script is not a low level type of tool that I feel will 
benefit from being in C, I feel it will in fact be worse off 
in C,

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation