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

From: Stefan Beller <stefanbeller@googlemail.com>
Date: Aug 14, 2013, 22:16 UTC
Message-ID: <520C01C3.2060804@googlemail.com>
In-Reply-To: <201308141125.59991.mfick@codeaurora.org>

On 08/14/2013 07:25 PM, Martin Fick wrote:

> 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...

It's ok, if you knew a better topic to work on, I'd gladly switch over. (Given it would be a good beginners topic.)

Show 10 quoted lines

>  
> 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.

Looking at the `git log -- git-repack.sh` the last commit is from April 2012 and the commit before is 2011, so I assumed it stable enough for porting over to C, as there is not much modification going on. I'd be glad to include these changes you're using into the rewrite or the shell script as of now.

Show 9 quoted lines

> 
> 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,

So far I have been following the git mailing list, there are people dreaming of 'everything in C' and apparently those, who are ok with lots of shell code as well, 'because it's high level'. I tend to follow the first group, dreaming of everything in C. Thanks for pointing that out, if it really hurts people from using git effectively, I'd rather not contribute this patch. But I'd like to stress again, that the prototying should be done by now.

I asked for a todo wish list a few weeks ago, but got no real answer, but rather: "Pick your choice and try to come up with good patches". This is a good policy from the projects point of view (your choice helps in doing good patches, and good patches do not need as much review, hence the reviewing costs are low), so I also choose this topic.

> 
> -Martin
>

Stefan